Summary

  • draft-ietf-tls-tlsflags-18 packs up to 2,040 content-free feature indications into one TLS extension. It is an active Proposed Standard-track Internet-Draft at I-D Exists, not an RFC or deployment report; revision 18 is a maintenance refresh.
  • A set bit can mean support or intent, can be a proposal, acknowledgement or permitted unsolicited indication, and can sit in a clear or encrypted handshake message. Each defining flag specification decides acknowledgement and 0-RTT semantics.
  • Daniel Kade proposes a flag interpretation envelope that preserves message, direction, role, defining reference, transcript evidence, resumption context, observed outcome and local decision. It is editorial guidance, not an IETF requirement.

The incident report looked reassuringly precise. It listed a timestamp, two addresses, a TLS version and flag 8 = true. The investigator read the last field as “feature active”. The collector had thrown away the handshake message, the sender’s role and the direction. Nobody could now tell whether the bit came from a client proposal, a NewSessionTicket announcement, or a response to something previously offered.

Nothing proved that the parser had read the wrong bit. The failure was the noun attached afterwards. An observation had become a state.

That mistake is easy to make because bits feel self-contained. They are not. In the TLS flags proposal, the same container can carry several independently defined features. A bit position identifies a specification; that specification tells the reader what presence means, which messages may carry it, whether a response is expected and how the feature behaves with early data. Strip those coordinates away and the stored boolean is no longer a faithful account of the exchange.

Revision 18 renews a draft; it does not complete it

draft-ietf-tls-tlsflags-18 was published on 10 September 2026. Datatracker describes it as an active TLS Working Group Internet-Draft, intended for the Proposed Standard track. Its IESG state is I-D Exists; the Working Group state is Waiting for Implementation. A shepherd is named, but there is no responsible Area Director or telechat date.

The document history matters because the date can otherwise look like a fresh protocol decision. The official 17→18 comparison changes the revision/date and expiry boilerplate, not the operative rules. Revision 18 keeps the work alive until March 2027. It does not make the document an RFC, record new interoperability evidence or complete the requested registry work.

The TLS Working Group owns an important standards problem: content-free TLS extensions cost four octets apiece even when presence carries the entire indication. A common bit string can make a growing family of such signals cheaper. That is an encoding achievement. It should not be represented as a universal feature-state machine.

The container compresses syntax, not semantics

The revision 18 text defines between one and 255 octets of flags, enough for positions 0 through 2,039. Bits are packed least-significant first within each octet. The sender must use the minimum length that reaches the highest set bit. An all-zero value or one with trailing zero octets is invalid, and the receiver must terminate with a fatal illegal_parameter alert.

Those rules let implementations agree on where a bit sits and reject non-canonical encodings. They do not say what every bit asserts. The draft’s own definition is deliberately broader: a flag-type feature is optional TLS 1.3 functionality whose empty extension, or corresponding bit, indicates support or intent to use. Support and intent are not synonyms.

A client may be capable of a feature but decline to propose it for this connection. A server may send a permitted unilateral indication in a NewSessionTicket about future resumption. A peer may acknowledge understanding without the application ever reaching the condition that exercises the feature. A policy engine may forbid use even after both endpoints signal compatibility.

The shared tls_flags extension cannot erase these distinctions because it was not designed to own them. The defining document for each flag must provide the missing semantics.

A proposal, an acknowledgement and an announcement are different events

The rules allow unsolicited flags only in ClientHello, CertificateRequest and NewSessionTicket. A flag appearing in ServerHello, EncryptedExtensions, Certificate or HelloRetryRequest must have been proposed in the applicable earlier ClientHello or CertificateRequest. Receiving an unsolicited response-position flag is fatal.

This yields evidence about the transcript, not a timeless object.

In ClientHello, a bit can be a proposal or expression of intent. In ServerHello or EncryptedExtensions, the same bit may acknowledge a preceding proposal when its defining specification requires acknowledgement. In NewSessionTicket, a server-side flag is never acknowledged because there is no client response message. In CertificateRequest and the client Certificate, the direction and roles reverse.

A database column named feature_supported cannot represent all of those cases. Even a pair of booleans called offered and accepted may be wrong for a flag that does not require acknowledgement. The model has to begin with the exchange: who sent which bit, in which handshake message, after which prior message, under which per-flag rule.

The Working Group reached this boundary explicitly. Issue 19 argued that acknowledgement should not be mandatory for the container and that each flag should specify its own behaviour. The resulting rule allows flags without responses. That history is not an implementation footnote; it prevents an observer from inferring a missing acknowledgement where none was defined.

The response rule is narrow on purpose

Where a flag does require acknowledgement, the response must be the same flag in tls_flags. The container must not be used when the response needs a conventional extension with content. That restriction keeps a one-bit acknowledgement from impersonating a structured negotiation.

It also limits what a successful exchange can prove. Matching proposal and acknowledgement shows that the peers followed the defining signalling rule. It does not prove that the feature later ran, produced the intended application result, remained enabled after policy evaluation or was safe for a use not covered by the specification.

RFC 8446 already offers a useful example. The empty post_handshake_auth extension says that a client is willing to perform post-handshake authentication. The server may later send a CertificateRequest. Willingness is not evidence that a later request occurred, that the client supplied a certificate, or that an application authorized the resulting identity. A content-free indication can be exact and still be only the first event in a longer chain.

Early data makes a timeless boolean especially dangerous

TLS 1.3 resumption can carry 0-RTT application data before the new handshake completes. The flags container can appear in the handshake messages of that exchange, but revision 18 does not give every future flag one common early-data meaning. Each flag specification must define its interaction with 0-RTT.

The boundary was recorded in the Working Group’s issue 16: the container is an encoding framework, while the individual trivial extensions remain responsible for early-data semantics. That is the right division of labour. One feature might be safe to remember across resumption; another may require a fresh acknowledgement; a third may affect only future tickets.

A collector that retains flag=true but drops whether the connection was full or resumed, whether early data was attempted or accepted, and which flag specification governed the exchange can apply a later state to earlier bytes. That is more than an observability defect. It can corrupt a security or compliance conclusion about what policy applied when an action occurred.

Message placement changes who can observe the bit

The draft warns that acknowledgements in ServerHello and HelloRetryRequest are exposed to passive observers. Most acknowledgements should instead appear in encrypted messages unless there is a specific reason to expose them.

Consequently, two records for the same flag can have different visibility authority. A path monitor may see a bit in ServerHello. It cannot assume that an equivalent bit in EncryptedExtensions was absent merely because it could not read it. An endpoint log can see the encrypted transcript but brings a different trust and retention boundary. A middlebox-generated summary may know only the clear handshake.

“Not observed” must therefore name the observation point. A passive capture, client endpoint, server endpoint and terminating proxy do not share one field of view. The flag’s message location is simultaneously a protocol coordinate and a disclosure decision.

Registry state is a map, not an execution trace

Revision 18 requests a TLS Flags registry with the fields Value, Flag Name, Message, Recommended and Reference. Values 0–15 would require Standards Action; values 16–2039 would use Specification Required under RFC 8126. The initial proposed flag is value 8, resumption_across_names, in NewSessionTicket, with Recommended N.

At the research cutoff, the live IANA TLS ExtensionType registry separately listed the tls_flags container itself as extension value 62, allowed in CH, SH, HRR, EE, CR, CT and NST, with Recommended N and a reference to draft revision 14. That is current registry evidence. It is not evidence that the draft has become an RFC, that the requested flag registry is complete, or that implementations support a particular flag.

RFC 8447 is unusually clear about this category mistake. Recommended N does not necessarily mean flawed; an item may have limited applicability, lack IETF consensus or serve a specific use. Designated-expert approval should not be read as endorsement. The current 8447bis work may refine registry language, while the current 8446bis work revises the protocol specification. Both remain works in progress.

A registry tells a parser which coordinate and reference to use. Only a transcript shows what was sent. Only the defining specification tells what it meant. Only local evidence shows what happened afterwards.

Invalid syntax proves a bounded failure

The fatal rules are useful because they prevent ambiguous encodings. A receiver can reject an all-zero value, trailing zero octets, a zero-length encoding or a flag sent in an impermissible response location. That gives a clean protocol result for this handshake.

It does not identify the organisational cause. The sender may have used an outdated library, a stale registry snapshot, a faulty serializer, a policy that enabled an experimental flag in the wrong message, or an attacker-controlled input. The fatal alert does not say which. Nor does a successful handshake prove that every application-level assumption about the feature was satisfied.

An incident record should preserve the raw bounded reason—message, direction, bytes, parser version and alert—before adding diagnosis. “Feature failure” is already an inference. “Received trailing-zero tls_flags in ServerHello and emitted illegal_parameter” is an observation.

Build a flag interpretation envelope

The repair is not another universal feature boolean. It is a small envelope around each observation.

Record the connection or transcript evidence reference without storing traffic secrets; TLS version; full or resumed handshake; 0-RTT offered, accepted or rejected; endpoint role and direction; exact handshake message; container extension value; raw bit-string hash and canonical length; bit position; registry snapshot; defining specification and revision; and whether the event is a proposal, acknowledgement or permitted unsolicited indication.

Then record whether acknowledgement is required for this flag, which prior proposal it answers, the matched peer evidence and any fatal validation result. Keep clear-text visibility separate from endpoint-only visibility. Name the parser build and policy version that interpreted the bit.

Finally, preserve the observed downstream outcome: understood, selected, exercised, failed, superseded or unknown. Attach the local decision that may rely on it, the decision owner, retention, permitted consumers, uncertainty, expiry and closure evidence. A security controller may require execution evidence; capacity research may need only an aggregate proposal count. The same bit is not equally sufficient for both.

This flag interpretation envelope is Daniel Kade’s governance proposal. It does not change TLS, allocate a number or add an IETF requirement. It keeps each institution from claiming more than its evidence provides.

Let the public claim rise one step at a time

“Bit 8 observed in a server NewSessionTicket” is a transcript claim. “The ticket announced cross-name resumption under specification revision R” is an interpretation claim. “The client later attempted that resumption” is an execution claim. “The server accepted it under policy P” is a decision claim. “The application treated the resulting identity as authorized” is a still later claim.

None should inherit the authority of the next.

Compression is valuable because it reduces repetitive syntax. Governance is valuable because it prevents that compressed syntax from becoming an inflated conclusion. A TLS flag can be perfect evidence of a bit in a message. It is not, on its own, a record of the feature’s state.

Sources