Кратко

  • 3 сентября 2026 года IESG одобрила редакцию 25 документа TLS/DTLS 1.3 Profiles for the Internet of Things как Proposed Standard. Окончательного номера RFC в уведомлении ещё не было.
  • Текст дополняет RFC 7925 и обновляет только профиль сертификатов X.509 и требования к наборам шифров; старые установки TLS/DTLS 1.2 остаются частью эксплуатационной реальности.
  • Сам проект проводит главную границу: совместимость протокола необходима, но недостаточна для совместимости на уровне аутентификации и авторизации.
  • Сертификат, необёрнутый открытый ключ и внешний PSK по-разному распределяют обязанности по идентичности, выдаче и замене. Успешное рукопожатие само по себе не выдаёт право на действие.
  • Нужна версионируемая квитанция границы полномочий: способ учётных данных, ожидаемая сторона, локальная политика, корень доверия, возраст сеанса, повторная проверка, безопасный отказ и откат — без публикации секретов.

Общий стандарт решает общую часть

Protocol Action — полноценное решение процесса IETF. Документ разработала группа Using TLS in Applications, а IESG после широкой поддержки одобрила его для Standards Track. Профиль сводит в единый набор требования к учётным данным, расширениям, ошибкам, возобновлению, forward secrecy, таймерам, размеру записей, сертификатам и наборам шифров TLS и DTLS 1.3 для ограниченных устройств.

Общий минимум нужен, потому что фраза «поддерживает TLS 1.3» слишком расплывчата. Производители могут вырезать разные функции ради памяти и энергии, по-разному понять обязательные расширения и всё равно заявлять совместимость. Профиль делает базу проверяемой.

Но одобрение не превращает базу в универсальный допуск. В версии 25 прямо сказано: совместимость TLS — обязательное основание, однако она не обеспечивает аутентификацию и авторизацию между разными системами. Протокол проверяет владение ключом в согласованном контексте. Оператор связывает ключ с ожидаемым аппаратом, назначает роль и разрешает конкретное действие.

Статус документа также состоит из отдельных состояний. Он одобрен как Proposed Standard, но уведомление ещё не присвоило ему окончательный номер RFC, а публикационная редактура не завершена. Это не Internet Standard и не сертификат продукта. Решение IESG доказывает судьбу текста, но не состояние чьей-либо прошивки.

Связь с RFC 7925 намеренно узкая. Новая работа меняет требования к сертификатам и ciphersuite для TLS/DTLS 1.3, а прежний профиль 1.2 продолжает применяться в долгоживущем промышленном парке. Смешение поколений допустимо; отсутствие точного реестра применяемых версий — уже риск.

Три способа доказать ключ, а не одно право

Профиль рассматривает сертификаты, raw public key и внешние PSK. Единственный вариант не навязывается: безопасность, цена, ресурсы и модель обслуживания различаются.

Сертификат X.509 связывает ключ с идентификатором через цепочку издателей. Различие между IDevID и LDevID показывает, что у идентичности есть этапы. Заводской IDevID обычно помогает первичному подключению; владелец или оператор выдаёт LDevID для эксплуатационного домена. Удобство не должно превращать долговечную заводскую метку в бессрочное разрешение на работу.

Raw public key уменьшает объём передачи, но требует внешней привязки ключа к ожидаемой стороне. Если SNI не отправляется из-за закреплённого ключа, сертификата, адреса или идентификатора PSK, другая привязка всё равно обязательна. Иначе можно безошибочно проверить ключ и ошибочно назначить ему сервис.

Внешний PSK переносит смысл в канал выдачи: его идентификатор, энтропия, область, разделение версий и замена определяются вне рукопожатия. Профиль требует по возможности применять (EC)DHE для forward secrecy. Режим PSK-only допустим лишь после явного принятия потери этого свойства в конкретном развёртывании. «Явно» означает ответственного, границы и срок.

SNI помогает выбрать серверный контекст, ALPN — протокол приложения. Ни то ни другое не предоставляет полномочия. Авторизация опирается на аутентифицированные данные и локальную политику.

Если устройство не проверяет отзыв, часы переходят оператору

Ограниченным устройствам часто не хватает ресурсов для OCSP или CRL во время рукопожатия. Версия 25 предлагает обычную альтернативу: короткоживущие эксплуатационные сертификаты, автоматизированное подключение и управление заменами. Отзыв не исчезает — меняются исполнитель и путь.

Замена сертификата не прерывает автоматически долгий TLS-сеанс. Протокол не требует постоянно повторять проверку после установления соединения. Если непрерывная действительность обязательна, приложение должно инициировать повторную аутентификацию либо разорвать и заново создать связь. Для взаимной post-handshake проверки нужен ещё и механизм протокола приложения.

Поэтому «новый сертификат доставлен» и «последний старый сеанс завершён» — разные квитанции. Между ними остаётся окно прежней авторизации. Панель, которая показывает только даты сертификатов, не измеряет это окно.

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

Сэкономленный байт меняет зависимость

В минимальном примере версии 25 два ECC-сертификата занимают около 40 процентов полезной нагрузки рукопожатия TLS 1.3 с взаимной аутентификацией без подчинённого CA. Короткие цепочки, сжатие, кэширование и возобновление действительно экономят радио, память и вычисления.

Однако число, срок и повторное использование билетов сеанса балансируют эту экономию с состоянием сервера, replay и приватностью. Внешняя загрузка сертификата добавляет зависимость от DNS или каталога и может раскрыть устойчивый идентификатор. Кэш требует правила инвалидирования. Уменьшение пакета переносит контроль свежести в другое место.

Правило 0-RTT особенно ясное. Протокол приложения не должен использовать ранние данные без отдельного профиля, который перечислит безопасные сообщения и откат к 1-RTT. На дату версии 25 такого профиля для CoAP и MQTT не было; этот документ не включает им 0-RTT. Техническая возможность не является разрешением.

Ошибки работают так же. У устройства без человека нет окна подтверждения. Приложение заранее решает, какой alert допускает повтор, альтернативный endpoint или credential, а какой переводит систему в безопасное состояние. TLS сообщает условие; оператор отвечает за последствие.

Квитанция на границе авторизации

Запись начинается с версии профиля и сборки. Затем она называет режим credentials, устойчивую ссылку, ожидаемую сторону, способ привязки, прикладной протокол и роль, версию локальной политики и класс разрешённого либо запрещённого действия.

Блок жизненного цикла содержит поколение trust anchor, сертификата или PSK, канал выдачи, наблюдаемую активацию, истечение и замену. Блок сеанса разделяет полный и возобновлённый handshake, сохраняет поколение ticket, начало, последнюю повторную проверку и максимальный возраст. Исключение forward secrecy получает владельца и дату окончания.

Блок безопасности связывает существенный сбой с повтором, резервом, деградацией или безопасной остановкой. 0-RTT отмечается выключенным либо, после появления будущего профиля, ограничивается классами сообщений и anti-replay состоянием. Исправление добавляет новую запись, а не стирает старую: прежние сеансы были открыты по прежнему правилу.

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

Идея минимальной спецификации из Note 64 Heng Lu применяется здесь только как редакционная граница. Общие правила должны быть минимальными, детерминированными и локально проверяемыми. Заметка не подтверждает конкретное развёртывание. Она не даёт IETF права писать одну таблицу доступа для всех и не позволяет локальной таблице скрыться за именем стандарта.

Чего одобрение не установило

Источники не сертифицируют продукт, парк или инцидент. IESG не выбирала CA, PSK, набор разрешений и безопасное состояние оператора. Proposed Standard не равен знаку безопасности устройства.

Профиль также не является постквантовым. Нормативные ciphersuite используют классическую криптографию; раздел PQC носит информационный характер и не вводит обязательств. Долгий срок устройств требует плана миграции, а не заявления о состоявшемся переходе.

Документ не утверждает, что каждое ограниченное устройство навсегда лишено OCSP или CRL. Он описывает распространённый предел и рекомендует оценку по ситуации. Более способная платформа может выбрать другой контроль.

Ценность решения именно в точном разделении. IETF уменьшает лишнюю несовместимость. Организация, разрешающая действие, сохраняет полномочие и обязанность доказать его состояние.

Источники

  1. IESG — Protocol Action для IoT-профиля
  2. IETF — одобренная версия 25
  3. RFC 9846 — TLS 1.3
  4. RFC 9147 — DTLS 1.3
  5. RFC 7925 — профили TLS/DTLS для IoT
  6. RFC 5280 — профиль PKI X.509
  7. RFC 9257 — внешние PSK
  8. RFC 9258 — импорт внешних PSK
  9. RFC 9019 — обновление прошивки IoT
  10. RFC 8995 — BRSKI
  11. RFC 9525 — идентичность сервиса TLS
  12. RFC 9325 — безопасное использование TLS и DTLS
  13. Heng Lu — Minimum Initial Specification