Кратко

  • Текущая версия — draft-ietf-tls-extended-key-update-13; заказанная версия 11 уже устарела, а документ остаётся Internet-Draft, не утверждённым RFC и не свидетельством внедрения.
  • Request, response и finish способны внести новый общий секрет, но ни одно из этих сообщений не подтверждает локальное уничтожение старых ключей и завершение перехода в обоих направлениях.
  • Вывод о восстановлении должен связать согласование, порядок сообщений, генерацию свежего материала, вывод секретов, удаление состояния, первые новые записи в каждом направлении и двустороннюю проверку приложения.

Сначала — точный статус документа

IETF Datatracker помечает версию 11 как предыдущую. Версия 13 опубликована 4 июля 2026 года и истекает 5 января 2027 года. Предполагаемый статус — Proposed Standard, но в IESG она имеет лишь состояние «I-D Exists», без ответственного Area Director и даты telechat.

Версия 13 переименовала подтип 2 в key_update_finish, уточнила защиту всех трёх сообщений старыми прикладными ключами и расширила границу для активного противника. Поэтому заявление о поддержке обязано называть версию и фактически наблюдаемое поведение. Формулировка «одобрено IETF» была бы неверной.

Поддержка, политика и сеанс — разные факты

Клиент предлагает Extended_Key_Update через TLS flags в ClientHello. Сервер подтверждает его в EncryptedExtensions только при наличии поддержки и включённой настройки. Без подтверждения приложение, которому нужна безопасность после компрометации, должно выполнить полный новый handshake.

После согласования EKU классический KeyUpdate запрещён и вызывает unexpected_message. Request и response должны использовать группу исходного handshake; другая группа приводит к illegal_parameter. Наличие кода, разрешение политики и согласование в конкретном сеансе нельзя сводить в один флаг.

Переключение не является атомарным

Инициатор отправляет key_update_request со свежим key share. Ответчик возвращает key_update_response и сначала меняет ключ отправки. Инициатор выводит новое состояние, меняет ключ приёма, отправляет пустой key_update_finish, всё ещё защищённый старым ключом, а затем меняет ключ отправки. Ответчик переключает приём только после проверки этого finish старым ключом.

В переходном окне одно направление уже может быть новым, а другое — старым. Единственное поле «версия ключа соединения» скрывает эту асимметрию. При встречных запросах проигрывает лексикографически меньшее значение key_exchange; равенство завершает соединение.

Вывод смешивает свежий общий секрет, значение, связанное с прежним main secret, и transcript hash исходного handshake и всех EKU. Затем создаются оба traffic secret, exporter secret и resumption main secret. В отличие от обычного KeyUpdate, новое состояние больше не определяется только скомпрометированной цепочкой.

Где заканчивается видимость протокола

Трассировка может показать новые shares и совместимые записи. Она не доказывает качество генератора случайных чисел, отсутствие повторного использования или удаление копий из heap, HSM, ядра и crash dump. Проект говорит, что прежние секреты СЛЕДУЕТ удалить как можно быстрее; удалённая сторона не может это засвидетельствовать.

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

Сам противник также должен потерять доступ к обеим сторонам. Постоянный нарушитель прочитает новое состояние; активный противник с текущими traffic keys способен подменить EKU-сообщения и сохранить MitM-позицию, если дополнительная аутентификация из раздела 11 не была реально выполнена и проверена. Восстановление одного соединения не исправляет скомпрометированный долгосрочный ключ идентификации.

В DTLS к доказательствам добавляются epochs, повторные передачи, временное хранение старого состояния и ACK. Инициатор завершает смену отправки только после подтверждения в новой эпохе. Панель TLS нельзя превратить в доказательство для DTLS простой заменой названия.

Источники