Кратко

  • draft-ietf-tls-tlsflags-18 помещает до 2040 бессодержательных признаков в одно расширение TLS. Это активный Internet-Draft с предполагаемым статусом Proposed Standard и состоянием I-D Exists, а не RFC или отчёт о внедрении; редакция 18 — обслуживание.
  • Бит может обозначать поддержку или намерение, предложение, подтверждение либо допустимое инициативное сообщение. Правила ответа и 0-RTT задаёт отдельная спецификация каждого флага.
  • Daniel Kade предлагает конверт интерпретации: сообщение, роль, направление, нормативная версия, transcript, возобновление, фактический результат и локальное решение. Это редакционное предложение, не требование IETF.

Команда считала долю серверов с включённой функцией TLS. Сборщик уже сохранял битовую строку, и запрос выглядел очевидно. Проверка показала, что в одну метрику попали предложения ClientHello, ответы сервера и объявления NewSessionTicket о будущем возобновлении.

Система верно сосчитала сигналы. Отчёт неверно назвал их включёнными функциями.

Свежая дата не завершает стандартизацию

Datatracker называет редакцию 18 от 10 сентября 2026 года активным документом TLS WG с намерением Proposed Standard. Состояние IESG — I-D Exists, группы — Waiting for Implementation. Ответственный AD и дата telechat отсутствуют.

История и официальное сравнение 17→18 показывают лишь замену номера, даты и срока действия. Рабочие правила не изменились. Продление до марта 2027 года не означает RFC, межоперабельность или распространённость.

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

Она унифицирует контейнер, но не жизненный цикл каждой функции.

Минимальная форма не создаёт полного смысла

Редакция 18 задаёт от одного до 255 октетов и позиции 0–2039. Биты идут от младшего, длина заканчивается октетом с самым высоким установленным битом. Полностью нулевое значение и конечные нулевые октеты недопустимы и вызывают фатальный illegal_parameter.

Так обе стороны находят один номер и отвергают неканоническую запись. Но присутствие flag-type feature означает поддержку или намерение использовать.

Поддержка — способность реализации. Намерение — выбор в одной сессии. Предложение — событие сообщения. Подтверждение — другое событие, если конкретный документ его требует. Реальное использование, результат и разрешение приложения происходят позднее.

Boolean enabled стирает все переходы.

Сообщение определяет действие

Инициативный флаг разрешён в ClientHello, CertificateRequest и NewSessionTicket. В ServerHello, EncryptedExtensions, Certificate или HelloRetryRequest он должен отвечать подходящему предыдущему предложению. Незатребованный ответ фатален.

В ClientHello предлагает клиент. В ServerHello или EncryptedExtensions сервер может подтвердить. В NewSessionTicket он сообщает без ответного сообщения клиента. В паре CertificateRequest/Certificate роли меняются.

Столбец «поддерживается» не различает действия. Универсальная пара offer/accept тоже неверна для флага без ответа. Issue 19 закрепляет решение: необходимость подтверждения определяет спецификация отдельного флага.

Поэтому отсутствие ответа не всегда отказ.

Подтверждение не равно выполнению

Если ответ нужен, им может быть только тот же бит в tls_flags. Когда ответ должен нести данные, требуется обычное содержательное расширение. Бит не должен изображать структурированное согласование.

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

RFC 8446 показывает это на post_handshake_auth. Клиент сообщает готовность к последующей аутентификации. Из этого не следует отправка CertificateRequest, предъявление сертификата или выдача доступа. Готовность, запрос, завершение и авторизация — четыре факта.

Для 0-RTT нужно сохранить время

При возобновлении TLS 1.3 данные 0-RTT могут уйти до завершения нового handshake. Контейнер флагов применим в сообщениях, но не задаёт универсальный смысл early data. Каждый документ флага должен описать взаимодействие сам.

Issue 16 проводит границу: контейнер отвечает за кодирование, представленные функции — за 0-RTT. Одно состояние наследуется из ticket, другому нужно свежее подтверждение, третье объявление касается лишь будущего возобновления.

Если потерять full/resumed, предложение и принятие 0-RTT, ticket и момент решения, поздний true начинает действовать задним числом. В вопросах личности и безопасности он приписывает ранним данным ещё не существовавшее разрешение.

Не увидел не значит не было

Проект предупреждает: подтверждения в ServerHello и HelloRetryRequest видны пассивному наблюдателю. Без особой причины лучше использовать зашифрованное сообщение.

Датчик на пути видит открытые позиции, но не EncryptedExtensions. Журнал endpoint видит расшифрованный transcript, однако имеет иную привилегию. TLS-терминатор свидетельствует о своём участке.

Утверждение «флаг отсутствовал» требует точки наблюдения, видимых сообщений, окна захвата и версии parser. Слепота датчика не является молчанием peer.

Реестр координирует номер, а не исполнение

Редакция 18 запрашивает реестр TLS Flags с Value, Flag Name, Message, Recommended и Reference. Значения 0–15 требуют Standards Action, 16–2039 — Specification Required по RFC 8126. Первым предлагается 8 resumption_across_names в NewSessionTicket с Recommended N.

На дату исследования реестр IANA ExtensionType отдельно показывал сам контейнер tls_flags: значение 62, сообщения CH/SH/HRR/EE/CR/CT/NST, Recommended N, ссылка на редакцию 14. Это состояние координации, не сертификат реализации конкретного флага.

RFC 8447 объясняет, что N не обязательно означает недостаток. Возможны ограниченная применимость, специальный случай или отсутствие нужного консенсуса. Решение designated expert не является рекомендацией. Issue 32 привела к модели Y/N/D и признанию, что поздний документ может изменить Recommended.

TLS 1.3 bis и TLS registry bis также остаются проектами. Реестр указывает правило; transcript и последующие события показывают, что произошло.

Фатальная ошибка не называет причину

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

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

Конверт интерпретации

Предложенный Daniel Kade конверт интерпретации флага хранит ограниченную ссылку на transcript без секретов, версию TLS, полный или возобновлённый handshake, состояние 0-RTT, роль и направление, точное сообщение, значение контейнера, хеш исходной строки, каноническую длину, позицию, snapshot реестра, определяющий документ и редакцию.

Затем он различает предложение, подтверждение и допустимое инициативное сообщение; указывает требование ответа, связанную раннюю посылку и результат проверки. Пассивная видимость отделяется от знания endpoint, сохраняются версии parser и политики.

Наконец фиксируется результат: понято, выбрано, применено, не сработало, заменено или неизвестно. Добавляются допустимое решение, владелец, потребители, хранение, неопределённость, срок и закрытие.

Это редакционный контроль, а не требование IETF и не изменение TLS. Он не позволяет истинному биту стать недоказанным состоянием.

Подниматься по ступеням

«Бит 8 увиден в NewSessionTicket» — наблюдение. «Сервер объявил возобновление между именами по редакции R» — интерпретация. «Клиент попытался» — исполнение. «Сервер принял по политике P» — решение. «Приложение разрешило личность» — новый уровень доказательства.

Контейнер экономит повторные байты. Он не должен экономить глаголы. Флаг TLS доказывает бит в сообщении; сам по себе он не записывает состояние функции.

Источники