Кратко

  • Проект Oblivious CoAP от 28 октября разделяет сведения между прокси и шлюзом: первый видит адрес клиента, второй расшифровывает запрос, но не получает этот адрес от прокси.
  • Раздел 7.1 прямо допускает лёгкий повтор защищённого запроса прокси или внешним противником. Для операций с побочным эффектом серверу нужны признаки первого сообщения и счётчик последующих.

Зашифрованное письмо можно переслать повторно, не вскрывая конверт. На этом простом трюке держится главный эксплуатационный вопрос нового проекта Oblivious CoAP. Формат помогает скрыть отправителя от получателя; он не лишает посредника возможности продублировать команду. Если команда меняет состояние, повтор уже касается не тайны переписки, а реального действия сервиса.

CoAP служит обмену запросами и ответами в сетях с ограниченными ресурсами. Авторы проекта называют среди возможных применений запросы DNS over CoAP, анонимную диагностику устройств и обращения к каталогу ресурсов. Клиент защищает исходный обмен для шлюза с помощью HPKE и передаёт пакет через прокси CoAP. Прокси знает сетевой адрес клиента, но не читает запрос. Шлюз читает запрос, не получая от прокси адрес отправителя. Если роли контролируются совместно и сопоставляют метаданные, разделение теряет смысл.

Конструкция родственна двухсторонней схеме Oblivious HTTP, однако учитывает обмен несколькими связанными сообщениями CoAP в одном контексте HPKE. Нужен и шлюз, согласный работать по этой схеме; обычный сервер не становится «невидящим» автоматически. Самое существенное предупреждение проекта находится в разделе 7.1: прокси либо внешний противник может без труда воспроизвести защищённый запрос.

Для действительно безопасного метода сервер может допустить повтор, но сначала обязан проверить, что обработка второго экземпляра безопасна. Когда запрос меняет состояние, сервер может распознать дубликат и прекратить его обработку. Первое сообщение различается по инкапсулированному значению HPKE enc или его хешу. Для следующих сообщений в том же контексте предусмотрен защищённый целостностью счётчик OCoAP count: сервер сравнивает его с окном повторов, привязанным к принимающему контексту. Защищённая опция Echo способна усилить проверку свежести.

Здесь появляется бухгалтерия, которой в рекламной формуле «прокси не знает содержимого» не видно. Шлюзу придётся помнить уже принятые признаки, а приложению — знать, какие методы терпят повтор. Дважды принятая телеметрия может испортить счёт; дважды выполненное изменение состояния может произвести второй эффект. Проект перечисляет механизмы распознавания, но не даёт измеренного объёма хранения, срока удержания окна, порядка восстановления после перезапуска или результатов эксплуатации.

Карточка Datatracker фиксирует индивидуальный проект Standards Track со статусом I-D Exists. Проверка для будущего оператора вполне конкретна: отправить зашифрованный запрос, его копию и следующее сообщение того же обмена; повторить опыт после перезапуска шлюза. В протоколе уже обозначены счётчики. Теперь нужно показать, что действие произошло один раз и что память о первом конверте пережила сбой.