Кратко

  • RFC 9852 / BCP 195, написанный Rich Salz и Nimrod Aviram, требует, чтобы новый протокол с TLS предполагал доступность TLS 1.3 и указывал его как значение по умолчанию. Обязанность относится к создаваемой спецификации.
  • Это не квитанция от работающей конечной точки. Согласованная версия, конфигурация, аутентификация другой стороны, принятие приложением и восстановление — отдельные факты. RFC прямо исключает DTLS из этого предписания.

Слово «должен» в стандарте полезно: оно не даёт представить уже определившийся технический выбор как нейтральный. Но нормативная фраза не становится от этого измерением. Если RFC требует TLS 1.3 по умолчанию, он не наблюдал, какую версию реально согласовали конкретный клиент и конкретная конечная точка.

RFC 9852, New Protocols Using TLS Must Require TLS 1.3, — Best Current Practice IETF, BCP 195. Rich Salz и Nimrod Aviram указаны как авторы, но результат является консенсусом IETF, а не индивидуальным заявлением об эксплуатации. Документ отвечает на точный вопрос проектирования: что должна написать новая спецификация, использующая TLS? Она должна исходить из доступности TLS 1.3 и сделать его значением по умолчанию.

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

Граница DTLS — часть смысла, а не сноска. RFC 9852 говорит, что предписание относится только к TLS. Поскольку DTLS 1.3 не получил широкого распространения или развёртывания, оно не распространяется на DTLS ни в одной версии. Короткая формула «TLS 1.3 обязателен» стирает границу, которую текст установил намеренно.

RFC объясняет направление тем, что TLS 1.3 широко используется, имеет всеобъемлющие доказательства безопасности и улучшает недостатки безопасности и приватности TLS 1.2. При этом в нём сказано, что TLS 1.2 при подходящей, часто специальной конфигурации может давать хорошие свойства. Миграция к постквантовой криптографии — один из доводов, но решение о том, когда конкретному приложению нужна PQC, находится вне области документа. Это основания для правила проектирования, а не телеметрия сервиса.

Примат работающего кода требует сохранять доказательства раздельно и связывать их явно. BCP доказывает правило проектирования; конфигурация — локальное намерение; наблюдение рукопожатия — факт одного соединения; записи аутентификации, приложения и восстановления доказывают иные факты. Одна метка соответствия не может заменить такую цепочку.

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

Источники