Кратко

  • 3 сентября 2026 года IESG одобрил профиль TLS/DTLS 1.3 для Интернета вещей как Proposed Standard. Он предусматривает замену корней доверия у долгоживущих устройств, но сам статус стандарта не доказывает состояние конкретного парка.
  • Нужен реестр на уровне устройства: разрешённая поставка, долговременная запись, активное поколение корня, фактически выбранная цепочка, последнее использование старой власти, граница отката и квитанция приложения.

Объявление IESG касается draft-ietf-uta-tls13-iot-profile-25. В Datatracker версия 25 отмечена как одобренная с отправленным объявлением; окончательного номера RFC на момент проверки не было. Одобренный текст дополняет RFC 7925 для TLS/DTLS 1.2 и обновляет требования к X.509 и наборам шифров.

Главный операционный вывод связан со сроками. Датчик способен пережить криптографический алгоритм, центр сертификации, производителя и сервисный контракт. Текст прямо указывает: неизменный корень на весь срок службы усложняет переход алгоритмов, смену CA, смену производителя и реакцию на инцидент.

Корень доверия — локальное решение о начале проверки цепочки. Корневой сертификат, присланный сервером в сообщении Certificate, нельзя считать доверенным только из-за этой доставки. Предпочтительная модель — снабдить устройство корнем вне рукопожатия и не передавать корень в цепочке.

Успешная сессия отвечает на слишком узкий вопрос

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

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

При смешанном парке расширение certificate_authorities помогает серверу выбрать цепочку, которую клиент объявляет поддерживаемой. Переходные сертификаты newWithOld и oldWithNew из RFC 9810 соединяют поколения. Они не заменяют внеполосную установку нового корня.

Мост без условия демонтажа сохраняет прежние полномочия. Демонтаж до обновления удалённого устройства может, напротив, уничтожить единственный аутентифицированный путь ремонта. Реестр должен показать последнее старое использование и первый самостоятельный новый путь для каждой группы.

Поставка пакета не равна смене доверия

Безопасное обновление прошивки может доставить новый корень. Архитектура SUIT в RFC 9019 различает автора, распространителя, устройство и отношения доверия. После доставки остаются проверка пакета, долговременная запись, активация, перезагрузка, чтение хранилища и соединение, реально использующее новый корень.

Кроме того, доставка корней через прошивку не обновляет автоматически конечные сертификаты и сертификаты подчинённых CA. RFC 7030 определяет EST для регистрации и получения сертификатов CA, однако поддержка и успешное выполнение — факты конкретного развёртывания.

Общий показатель «98%» стирает последствия. Оставшиеся два процента могут быть дешёвыми датчиками или единственными контроллерами удалённого объекта. Нужны идентичность устройства, поколения аппаратуры и ПО, отпечатки корней, результат, момент активации, последний контакт и владелец исключения.

У трёх способов аутентификации три модели хранения

Профиль рассматривает X.509, сырые открытые ключи и внешние PSK, не выбирая один способ для всех IoT-систем.

В X.509 отдельно существуют корень доверия, возможные подчинённые CA и конечный сертификат. Raw Public Key по RFC 7250 убирает структуру сертификата из обмена, но сам не связывает ключ с ожидаемой стороной. Нужна защищённая привязка. Самоподписанный X.509 остаётся сертификатом X.509.

Внешний PSK перемещает контроль в жизненный цикл секрета. RFC 9257 описывает риски энтропии, идентичности и развёртывания. RFC 9258 привязывает импорт к KDF и контексту хеша TLS 1.3. Всё равно требуется знать автора секрета, круг копий, расписание ротации и допустимые сервисы.

Следовательно, поле «TLS включён» скрывает критическое различие в хранителе полномочий.

Оптимизация переносит стоимость

Если требование по умолчанию — около 18 КБ буферов обработки — чрезмерно, Record Size Limit из RFC 8449 позволяет объявить максимальную принимаемую запись. Это число не измеряет всю RAM, flash, энергию или время проверки сертификатов.

Возобновление сессии по RFC 9846 сокращает повторную сертификатную аутентификацию. Число, срок и повторное использование билетов влияют на состояние сервера, приватность и replay-контроль. Профиль IoT сам по себе не разрешает 0-RTT для CoAP либо MQTT без прикладного профиля.

Сжатие сертификатов, кэшированные сведения и URL сертификата экономят трафик, но могут добавить кэш, сервис получения, стабильный идентификатор и новую точку отказа. Меньший обмен не обязательно означает меньшую поверхность власти.

Реестр поколений доверия

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

Отдельно фиксируются предъявленная сервисом и принятая устройством цепочки: конечный сертификат, подчинённый путь, поколение корня, согласованный протокол и время. Квитанция приложения остаётся отдельной. Рукопожатие не доказывает, что команда была разрешена, зафиксирована либо физически выполнена.

Дисциплина слоёв реальности Lu Heng разделяет символический статус стандарта, настроенное хранилище, выполненную проверку и результат. Running-Code Primacy ставит наблюдаемое устройство выше паспорта продукта. Минимальная начальная спецификация и локальное будущее решение объясняют, почему совместимость не требует единственной архитектуры CA.

Источники