Кратко

  • 3 сентября 2026 года IESG одобрил редакцию 10 ML-KEM Post-Quantum Key Agreement for TLS 1.3 для публикации как Informational RFC. На момент проверки номер RFC ещё не был присвоен.
  • MLKEM512, MLKEM768 и MLKEM1024 получили значения NamedGroup с DTLS-OK=Y и Recommended=N. По RFC 9847 N не означает ни рекомендацию, ни признание дефекта, ни запрет.

Самая опасная строка в заявке на изменение может выглядеть вполне официально: «документ одобрен IETF». Если из неё сразу следует включение функции по умолчанию, публикационный статус подменил локальную оценку. Обратная ошибка возникает, когда одна буква N превращается в бессрочный запрет.

Редакция 10 описывает полноценный обмен. KeyGen создаёт открытый ключ инкапсуляции и секретный ключ декапсуляции. Клиент помещает открытый ключ в key_share. Сервер выполняет Encaps, получает ciphertext и общий секрет, а ciphertext отправляет в ServerHello. Клиент применяет Decaps; совпавший 32-байтовый секрет поступает в расписание ключей TLS 1.3 вместо секрета (EC)DHE.

Значения 512, 513 и 514 соответствуют MLKEM512, MLKEM768 и MLKEM1024. Размеры открытых ключей — 800, 1 184 и 1 568 байт; ciphertext — 768, 1 088 и 1 568 байт. Это параметры протокола, а не измерение задержки, фрагментации или ёмкости оборудования.

Сервер обязан проверить ключ по FIPS 203 и завершить соединение с illegal_parameter при ошибке. Клиент сверяет длину ciphertext с выбранным набором. Иные ошибки декапсуляции дают internal_error. Поля key share входят в transcript, связывая ключ и ciphertext с handshake.

Точная схема не подтверждает конкретную реализацию. Случайность при создании ciphertext и сам ciphertext запрещено использовать повторно. Владелец секретного ключа точно восстанавливает случайность инкапсуляции; слабый RNG может раскрыть связь с другими выходами или внутренним состоянием. FIPS 203, NIST SP 800-227 и RFC 8937 дают правила, но не аттестуют конкретную сборку.

При проверке 5 сентября в живом реестре IANA уже были все три строки. Ссылка ещё вела на редакцию 05 прежнего индивидуального проекта, тогда как Datatracker показывал одобренную редакцию 10 и продолжающуюся работу IANA. Это временный снимок проекции, который следует датировать и перепроверить, а не объявлять постоянной ошибкой.

RFC 9847 разделяет три состояния. Y фиксирует консенсус IETF о пригодности для указанной цели. D означает обоснованное нежелательное использование. N означает отсутствие заявления IETF о пригодности; причиной могут быть ограниченная область, условия применения или отсутствие консенсуса. Оно не объявляет механизм неисправным.

Поле DTLS-OK=Y отвечает на отдельный вопрос применимости в DTLS. Оно не подтверждает библиотеку, источник энтропии, сетевой путь или приложение. Объединение двух колонок в один зелёный индикатор создаёт рекомендацию, которой нет.

RFC 10024 позволяет увидеть контраст с гибридными группами: X25519MLKEM768 сейчас отмечен Y, а ряд других комбинаций — N. Новый документ прямо оставляет выбор автономной или гибридной схемы оценке безопасности, производительности и эксплуатации.

Решение о внедрении должно сохранять редакцию документа, снимок IANA, сборку библиотеки и модуля, RNG и reseed, конфигурацию каждого терминатора, предложение ClientHello, выбор ServerHello, ошибки проверки, завершённый handshake и ответ приложения. Конфигурация не доказывает трафик, предложение — выбор, а handshake — услугу или полномочие.

Принцип работающего кода Lu Heng возвращает ответственность правильному субъекту. Минимальная общая спецификация согласует номера, байты и отказы. Оператор, несущий последствия, разрешает эксперимент и rollback. Слои реальности не позволяют официальной записи выдавать себя за результат.

IESG сделал три механизма готовыми к публикации, IANA — адресуемыми. N сохраняет вопрос общей пригодности открытым. Ответ должен дать локальный владелец риска, опираясь на наблюдаемое выполнение.

Источники