Кратко

  • RFC 9973 вводит выбранный внешний PSK и общий секрет (EC)DHE в расписание ключей TLS 1.3, не заменяя сертификатную аутентификацию.
  • Выбранный идентификатор и binder показывают совпадение секрета в данном рукопожатии, а не его происхождение, круг хранения, допустимую цель или право на последующее действие.
  • Контроль должен отдельно фиксировать создание и поставку секрета, переговоры TLS, проверку сертификата, решение приложения, commit и наблюдаемый эффект.

Пусть организация принимает партию контроллеров. Для начального подключения каждый получил открытый ключ и заводской секрет. Инженер видит успешное соединение и считает ввод в эксплуатацию завершённым. Но владелец риска должен спросить иначе: был ли секрет уникален для одного контроллера; кто видел его при производстве; в каком виде он передавался; может ли сервис восстановления снова выдать его; для какого домена и протокольной версии он разрешён?

RFC 9973 — стандарт IETF, опубликованный в июле 2026 года вместо экспериментального RFC 8773. Она определяет tls_cert_with_extern_psk. При успехе выбранный внешний PSK и результат (EC)DHE становятся входами расписания ключей TLS 1.3. Подлинность сервера, а при необходимости клиента, по-прежнему зависит от подписей, проверяемых открытыми ключами сертификатов. Resumption PSK возникает из предыдущего соединения; external PSK получен иным путём. Их нельзя считать взаимозаменяемыми только потому, что оба называются PSK.

Клиент обязан сопровождать расширение key_share, supported_groups, psk_key_exchange_modes и pre_shared_key и не должен соединять его с early_data. Для первого рукопожатия используется psk_dhe_ke; перечисленные ключи должны быть внешними PSK. Сервер посылает расширение только если принимает один из предложенных внешних PSK и одновременно выполняет сертификатную аутентификацию. Реестр IANA закрепляет номер 33, но не говорит, что какой-либо продукт его поддерживает.

Совпадение ключа не равно истории ключа

Сервер выбирает позицию в списке идентификаторов клиента. Binder строится с HMAC из PSK и части transcript; его проверка показывает, что обе стороны сопоставили выбранной позиции одинаковое значение. Это строгий, но ограниченный вывод. Он не доказывает, что секрет создан хорошим генератором, не утекал из фабрики, известен только двум сторонам, не используется другой системой и не наделяет устройство правом менять данные.

RFC 9973 сознательно оставляет создание, распределение и управление внешним PSK за пределами своей области. Одновременно описываемая ею долгосрочная конфиденциальность зависит от конфиденциальности, энтропии и подлинности PSK. Норма требует безопасного управления ключами и предупреждает об опасности слабого псевдослучайного генератора. RFC 4086 помогает сформулировать требования к случайности, но не удостоверяет конкретный производственный процесс.

Внешний PSK не становится единственным основанием аутентификации. Добавление сильного секрета может, при указанных условиях, сохранить часть конфиденциальности, если будущий противник научится ломать (EC)DH, но не получит PSK. Проблема будущей стойкости подписи сертификата этим не снимается. RFC 9958 задаёт технический контекст, а не присваивает установке ярлык «квантово-безопасной».

Повторное применение секрета меняет свойства системы. Одноразовый PSK, известный лишь двум сторонам, отличается от значения для многих сессий или группы. Идентификатор PSK передаётся в открытом ClientHello и способен помогать связывать соединения. Ротация и Encrypted Client Hello могут уменьшить риск, но не решают, кто вправе получить новую идентичность и как подтверждается уничтожение старой.

Наблюдаемая цепочка вместо одной отметки успеха

Для каждого класса внешних PSK нужен безопасный реестр: цель, способ создания или деривации, разрешённые стороны, версия TLS и хэш, путь поставки, хранители, предел повторного применения, условия ротации и удаления. Сам секрет не следует размножать в журналах; нужны безопасные ссылки и свидетельства событий. От TLS остаются доказательства offer/accept, защищённая ссылка на выбранный идентификатор, psk_dhe_ke, результат проверки сертификата и Finished либо alert.

От приложения требуется другой слой: какой принципал и какая политика разрешили регистрацию или операцию, были ли соблюдены свежесть и защита от повтора, состоялся ли commit и подтвердил ли независимый наблюдатель эффект. Принцип Heng Lu о приоритете работающего кода требует смотреть на исполненный путь, а не на опцию в конфигурации. Его различие между формальным и практическим контролем требует выяснить не только владельца в инвентаре, но и того, кто сегодня способен извлечь или восстановить PSK.

Источники