Resumo

  • draft-ietf-tls-tlsflags-18 compacta até 2.040 indicações sem conteúdo em uma extensão TLS. Continua Internet-Draft ativo, destinado a Proposed Standard e em I-D Exists; não é RFC nem evidência de implantação.
  • Um bit pode indicar suporte ou intenção, proposta, confirmação ou anúncio permitido. A especificação de cada sinalizador define mensagens, necessidade de resposta e interação com 0-RTT.
  • Daniel Kade propõe um envelope de interpretação que liga bit, mensagem, papel, direção, referência, transcript, retomada, resultado e decisão local. É orientação editorial, não requisito do IETF.

Uma equipe precisava responder se certo recurso TLS estava habilitado. O painel mostrou uma linha verde: o bit correspondente apareceu. Depois se descobriu que os registros vinham de NewSessionTicket e descreviam uma possibilidade de retomada futura. Nenhuma tentativa posterior havia sido ligada àquela linha.

O erro não estava na captura. Estava na passagem silenciosa de “apareceu” para “está ativo”.

Uma manutenção recente não encerra o processo

O Datatracker registra a revisão 18, de 10 de setembro de 2026, como Internet-Draft ativo do TLS WG, com destino Proposed Standard. O estado no IESG é I-D Exists; no grupo, Waiting for Implementation. Não há AD responsável nem data de telechat.

O histórico e o diff oficial 17→18 mostram apenas atualização de revisão, data e expiração. A nova edição mantém o trabalho vivo até março de 2027. Não acrescenta regra operacional, teste de interoperabilidade ou aprovação final.

O TLS WG trata de uma ineficiência concreta. Uma extensão cuja única informação é sua presença ainda custa quatro octetos. Vários recursos opcionais repetem o mesmo invólucro. Reunir indicações em bits diminui o custo marginal.

Isso padroniza o recipiente, não o ciclo de vida de todos os recursos.

Forma mínima não é significado completo

A revisão 18 usa de um a 255 octetos e permite posições 0–2039. Os bits são colocados a partir do menos significativo; o último octeto deve conter o bit mais alto que esteja ligado. Tudo zero ou bytes zero no final tornam a extensão inválida e exigem illegal_parameter fatal.

Essas regras dão uma posição inequívoca e eliminam codificações não mínimas. Mas a própria definição admite que a presença indique suporte ou intenção de uso.

Suporte é capacidade da implementação. Intenção é escolha para uma interação. Proposta é um evento no handshake. Confirmação é outro, quando a especificação particular a exige. Execução e resultado ficam depois. Autorização de negócio ou segurança pertence a uma política local.

O campo enabled=true atravessa todas essas fronteiras sem prova.

A mensagem dá o verbo ao bit

Sinalizadores não solicitados podem aparecer em ClientHello, CertificateRequest e NewSessionTicket. Em ServerHello, EncryptedExtensions, Certificate ou HelloRetryRequest, precisam responder a proposta anterior pertinente. Uma resposta não solicitada encerra o handshake.

No ClientHello, o cliente propõe. Em ServerHello ou EncryptedExtensions, o servidor pode confirmar. Em NewSessionTicket, o servidor anuncia sem mensagem de resposta do cliente. Em CertificateRequest e Certificate, a direção dos papéis muda.

Uma única coluna de suporte não modela esses atos. Nem um esquema universal offer/accept serve para sinalizadores sem confirmação. A issue 19 documenta por que a exigência de resposta ficou com cada especificação de flag.

Ausência de confirmação pode significar rejeição, perda, invisibilidade — ou simplesmente que nenhuma confirmação era definida.

Confirmar o bit não confirma o efeito

Quando há confirmação, a resposta correta é o mesmo bit em tls_flags. Se o recurso precisa devolver dados, deve usar uma extensão com conteúdo. O recipiente de bits não pode substituir uma negociação estruturada.

Bits correspondentes provam que os pares seguiram uma regra de sinalização. Não provam que o recurso foi exercido, que funcionou, que permaneceu permitido após avaliação de política ou que uma aplicação aceitou a consequência.

RFC 8446 fornece o exemplo de post_handshake_auth. O cliente declara disposição para autenticação posterior. Isso não demonstra que o servidor mandou CertificateRequest, que um certificado foi apresentado nem que a identidade recebeu acesso. Disposição, pedido, conclusão e autorização são fatos distintos.

0-RTT exige conservar a ordem das decisões

Na retomada TLS 1.3, dados 0-RTT podem sair antes do novo handshake terminar. O recipiente pode aparecer nessa troca, mas não fornece uma semântica precoce universal. Cada documento de sinalizador deve definir sua própria interação com early data.

A issue 16 preserva essa divisão: tls_flags é framework de codificação; as extensões representadas respondem por 0-RTT. Um estado pode ser lembrado do ticket, outro pedir nova confirmação, outro valer apenas para uma retomada posterior.

Sem registrar full/resumed, oferta e aceitação 0-RTT, ticket e instante, o coletor pode aplicar retroativamente um true conhecido mais tarde. Em um controle de identidade, isso atribui autoridade a bytes enviados antes da decisão.

Ausência depende de quem podia ver

O texto avisa que confirmações em ServerHello e HelloRetryRequest ficam visíveis a observadores passivos. Na maioria dos casos, mensagens criptografadas são preferíveis quando a exposição não é necessária.

Uma sonda de caminho enxerga posições claras e não pode concluir sobre EncryptedExtensions. Um endpoint vê o transcript aberto, mas carrega outro nível de privilégio. Um proxy terminador descreve o trecho em que participa.

“Não observado” deve incluir ponto de observação, mensagens visíveis, janela de captura e versão do parser. Silêncio do sensor não é silêncio do peer.

Registro coordena número, não comprova uso

A revisão 18 pede um registro TLS Flags com Value, Flag Name, Message, Recommended e Reference. Valores 0–15 usariam Standards Action; 16–2039, Specification Required conforme RFC 8126. A entrada inicial proposta é o valor 8 resumption_across_names, em NewSessionTicket, Recommended N.

No corte da pesquisa, o registro IANA ExtensionType já mostrava o recipiente tls_flags como extensão 62, nos contextos CH/SH/HRR/EE/CR/CT/NST, Recommended N, referindo a revisão 14. Essa linha é estado de coordenação; não certifica suporte de produto nem ativação de flag.

RFC 8447 explica que N não quer dizer defeituoso. Pode significar aplicabilidade limitada, uso específico ou consenso ainda insuficiente. Aprovação por designated expert também não é endosso. A issue 32 alinhou o campo a Y/N/D e reconheceu que documentos posteriores podem alterar Recommended.

Os trabalhos atuais TLS 1.3 bis e registry bis continuam em andamento. O registro aponta para a norma; o transcript prova a mensagem; o sistema local precisa provar o resultado.

Alerta fatal não identifica a causa

Um valor todo zero, comprimento não mínimo ou resposta sem proposta pode terminar a conexão. O registro pode afirmar mensagem, direção, bytes, regra e alerta.

Não deve inferir automaticamente biblioteca antiga, snapshot vencido, serializador defeituoso, política experimental ou ataque. Esses diagnósticos precisam de evidência própria. Primeiro se preserva o evento de protocolo; depois vêm causa, responsável, correção e autorização para retomar.

O envelope de interpretação

Daniel Kade propõe um envelope de interpretação do sinalizador.

Ele guarda referência limitada ao transcript sem expor segredos; versão TLS; handshake completo ou retomado; 0-RTT oferecido, aceito ou rejeitado; papel, direção e mensagem; valor do recipiente; hash da cadeia bruta, comprimento canônico e posição; snapshot de registro; documento definidor e revisão.

Depois classifica proposta, confirmação ou anúncio permitido, registra se a resposta era obrigatória, liga a proposta anterior e preserva a validação. Visibilidade passiva e de endpoint ficam separadas, com versões do parser e da política.

Por fim, registra o que ocorreu: entendido, selecionado, exercido, falhou, foi substituído ou permanece desconhecido. Nomeia decisão permitida, dono, consumidores, retenção, incerteza, expiração e fechamento.

Esse envelope não está no draft e não muda TLS. É governança editorial para impedir que uma observação verdadeira receba autoridade maior do que seu contexto.

Afirmações em degraus

“Bit 8 visto no NewSessionTicket” é observação. “Servidor anunciou retomada entre nomes sob a revisão R” é interpretação. “Cliente tentou depois” é execução. “Servidor aceitou sob a política P” é decisão. “Aplicação autorizou a identidade” requer outra prova.

O ganho do recipiente é economizar bytes repetidos. A operação não deve economizar os verbos. Um sinalizador TLS prova um bit numa mensagem; sozinho, não registra o estado do recurso.

Fontes