Кратко

  • Индивидуальный Internet-Draft от 27 октября предлагает выбирать для TLS 1.3 ключевую схему SHAKE256 или TurboSHAKE256 отдельно от набора шифров. В редакции 01 появились правила для DTLS и Exported Authenticator, которые июльская редакция 00 исключала.
  • Если аутентификатор после рукопожатия живёт вне TLS-библиотеки, ему надо сообщить выбранный идентификатор KDF либо отсутствие новой KDF, а также различить TLS и DTLS. Привычный вызов экспортера этих сведений не передаёт.

Проверка соединения дала зелёный свет. TLS-библиотеку обновили. После рукопожатия доказательство личности строит другой компонент, и вот он всё ещё смотрит на старую вывеску: TLS_AES_128_GCM_SHA256. Редакция 01 проекта XOF key schedule предлагает отдельное расширение schedule_profile: оно выбирает SHAKE256 или TurboSHAKE256 независимо от набора шифров. Набор продолжает задавать AEAD, но его именованный хеш уже не управляет ключевой схемой при выборе новой KDF. Вывеска осталась, механизм внутри сменился.

В редакции 00 от июля этот проект прямо обходил DTLS 1.3 и Exported Authenticator. Поправка от 27 октября включает оба случая и предлагает обновить четыре RFC. Один из них, RFC 9261, позволяет сторонам удостоверять себя уже после рукопожатия. В нынешних правилах хеш такого аутентификатора связан с хешем набора шифров. Раздел 14.2 новой редакции привязывает его к выбранной KDF: TranscriptHash длиной 64 октета, значения экспортера и MAC поля Finished следуют правилам XOF.

На соединении без нового расширения остаются обычный график TLS 1.3 и прежние правила RFC 9261. Значит, компоненту снаружи нужен не красивый ответ «поддерживается XOF», а результат конкретных переговоров. Проект требует передать ему идентификатор KDF или явное сообщение, что альтернативу не выбрали. Плюс один бит контекста: TLS либо DTLS. Для DTLS предусмотрена другая метка ключевой схемы.

Вызов TLS-Exporter(label, context, length) отдаёт производные байты, но не сообщает ни фактическую KDF, ни разновидность протокола. Разработчик библиотеки может завершить новую реализацию, а команда приложения — продолжать собирать аутентификатор по старым допущениям. В самом проекте такой результат назван несовместимым. Здесь отказ возможен на границе команд и API, даже когда криптографические операции по отдельности работают.

Поправка также закрепляет KDF за заранее общими ключами и билетами возобновления; для PSK она использует идентификаторы RFC 9258. Подпись сертификата выбирается отдельно, поэтому уход SHA-2 из ключевой схемы не удаляет его из всей аутентификации. Datatracker по-прежнему показывает индивидуальный проект со статусом I-D Exists. В проверенных материалах нет опубликованного результата межбиблиотечной проверки нового перехода. Успешное доказательство после рукопожатия с XOF для TLS и DTLS закрыло бы этот пробел.