Кратко

  • Редакция 01 проекта MBONED — активный Internet-Draft предполагаемого информационного статуса, а не RFC, внедрение или результат совместимости.
  • Аутентифицированный манифест может связать упорядоченные хеши с пакетами, но его собственный канал, область покрытия и связь с запросом требуют отдельных доказательств.
  • Общая ключевая материя позволяет расшифровать поток, но не доказывает отправителя; наивная симметричная схема может дать получателю возможность подделки.
  • Источник, целостность, повтор, потеря, запрос, разрешение браузера, применение объекта и наблюдаемый эффект — разные квитанции.

Манифест наследует доверие своего канала

AMBI-подобная конструкция выносит асимметричную проверку в упорядоченный список хешей пакетов. Клиент получает манифест по аутентифицированному внешнему каналу, затем сравнивает содержимое multicast с ожидаемыми значениями. Порядок списка способен показать повтор, перестановку и отсутствие пакета.

Но манифест не появляется из пустоты. Клиент должен знать, почему канал манифеста относится к нужному источнику и объекту. HTTPS-адрес, переданный исходной страницей, может быть одним вариантом. Успешный TLS-сеанс доказывает защищённую связь с именем; связь имени, манифеста, канала и текущего запроса остаётся частью протокола.

Даже идеальное совпадение всех хешей утверждает лишь то, что полученные пакеты соответствуют подписанному списку. Оно не выдаёт пользователю право на объект, не доказывает актуальность запроса и не подтверждает результат обработки.

Покрытие важнее зелёного значка

Манифест должен явно определять, какие пакеты и какой порядок он покрывает. Пропущенная запись может означать потерю, неполный манифест, другую версию или ошибку производства. Система не должна автоматически превращать отсутствие в разрешение использовать то, что удалось собрать.

Полезно хранить идентификатор манифеста, источник, эпоху, диапазон последовательности, время получения, проверку подписи или канала, найденные хеши, пробелы и решение о выпуске. Один флаг verified скрывает, был ли проверен весь объект или только доступная часть.

Если обновлённый манифест приходит после данных, возникает временная граница. До завершения проверки пакеты не должны попадать в приложение. Скорость загрузки не может заменить область доказательства.

Расшифровка не устанавливает автора

Для общей зашифрованной доставки нескольким получателям нужна общая ключевая материя. В наивной симметричной конструкции тот же секрет может создавать теги аутентификации. Любой владелец ключа, включая разрешённого получателя, способен создать тег, принимаемый другими участниками.

Это не универсальная оценка всех групповых протоколов. Требование состоит в асимметрии источника для каждой единицы. Подпись оставляет закрытый ключ у отправителя. TESLA раскрывает симметричный ключ после окна доставки. Манифест переносит асимметрию во внешний доверенный документ.

Каждый подход создаёт остаточный риск. Подписи зависят от происхождения открытого ключа. TESLA — от часов и задержки. Манифест — от своего канала и полноты. Возможность расшифровать полезную нагрузку не закрывает ни один из этих вопросов.

Проверка объекта может запоздать

Если аутентификация выполняется только после сборки всего объекта, один внедрённый пакет может заставить получателей хранить, сортировать, исправлять и частично декодировать данные до финального отказа. Запросы unicast-восстановления увеличивают нагрузку поставщика.

Проверка по пакетам уменьшает окно. Но UDP не обеспечивает надёжность, порядок, устранение дубликатов и защиту от повторов. Нумерация, интервалы TESLA или строгий манифест должны отдельно выявлять повтор, перестановку и удаление.

Для браузера это граница доверенной вычислительной базы. Непроверенные байты не должны доходить до сложных парсеров и рендеринга. Манифест полезен лишь тогда, когда его решение предшествует использованию.

Правильные пакеты могут отвечать другому запросу

В HTTPS запрос и ответ связаны внутри защищённого двустороннего обмена. Multicast естественно однонаправлен и не несёт индивидуальный запрос клиента. Два канала могут быть подписаны одним правильным источником, но обслуживать разные версии или права.

Без дополнительной криптографической привязки атакующий на пути может поменять пакеты между двумя доверенными каналами. Хеши и подпись манифеста останутся корректными для своего объекта. Ошибка находится в утверждении, что объект отвечает текущему запросу.

Нужны отдельные доказательства: кто создал объект, какие пакеты в него входят, какой запрос его вызвал, разрешено ли приложение и что произошло после обработки. Манифест завершает только часть цепочки.

Шифрование не скрывает коллективную доставку

Шифрование защищает содержимое от не имеющих ключа, но размеры, время, адреса и шаблоны могут остаться видимыми. Наблюдатель способен установить, что одинаковая зашифрованная нагрузка пошла к нескольким получателям.

IGMP или MLD может показать, что некоторая сущность ниже точки наблюдения присоединилась к каналу. Это не всегда указывает точного человека, однако не является полной анонимностью. Перемещение подписки между сетями может связать членство с метаданными зашифрованного канала управления.

Компрометация одного устройства раскрывает ключ и содержимое эпохи. Индивидуальная выдача через канал с прямой секретностью, короткие эпохи и фактическое удаление ограничивают окно. Настроенная ротация не доказывает, что старый ключ исчез.

Браузер и сеть принимают разные решения

Враждебный origin может заставить браузер присоединиться ко многим каналам. Браузер должен ограничивать связь с хостящей страницей или требовать явное междоменное разрешение. Это защищает пользователя от сайта.

Маршрутизатор видит нагрузку и может применить ограничитель при злоупотреблении, например остановить непопулярный контент. Он защищает общую ёмкость. Ни один из этих механизмов не заменяет проверку источника и решение приложения.

В приватном режиме вступление должно требовать явного согласия, поскольку сетевые элементы получают метаданные. Согласие разрешает наблюдаемое действие, но не подтверждает каждый пакет и не гарантирует просмотр.

Операционный реестр должен сохранять незавершённость

Записывайте допуск получателя, разрешение, эпоху ключа, доставку, источник манифеста, его подпись и покрытие, хеш каждого пакета, последовательность, повторы, пробелы, восстановление, привязку к запросу, разрешение origin, приватное согласие, выпуск парсеру и результат приложения.

Не храните групповые секреты и личные данные. Идентификаторы можно хешировать и ограничивать эпохой. Задача журнала — показать, какое утверждение было доказано и какое оставалось открытым.

Предупреждения нужны для общего секрета как единственного доказательства источника, использования до проверки, неполного манифеста, данных после раскрытия TESLA, непропорционального восстановления, обмена каналов, вступления без связи с origin, приватного вступления без согласия и принятия после отзыва эпохи.

Источники и ограничения

Зафиксированный набор включает редакцию 01 и её Datatracker-статус, историю и ссылки, MBONED, RFC моделей угроз Internet и UDP, SSM и отказ от междоменного ASM, TLS 1.3, TESLA, NORM, ALC и multicast-аутентификацию, безопасность WebRTC, Client Hints, QUIC, WebTransport и AMBI.

Источники подтверждают текст и официальный статус. Они не подтверждают внедрение, распространение, производительность, реальную подделку, компрометацию, утечку приватности или результат приложения. Начальный пример сконструирован для проверки предела манифеста.

Источники