Resumo

  • A RFC 9662 acrescenta ECDHE/GCM ao piso comum, mantém RSA/CBC como capacidade obrigatória durante a migração e diferencia as exigências de versão para TLS e DTLS.
  • Permitir temporariamente a opção antiga pode evitar um apagão de telemetria, mas precisa de dono, prazo, uso observado e plano de atualização.
  • Nem a compatibilidade nem um handshake moderno provam a entrega; o recibo precisa unir conexão, identidade do evento, aceite, escrita durável, índice e releitura.

O equipamento industrial não podia ser atualizado naquela parada. A equipe manteve TLS_RSA_WITH_AES_128_CBC_SHA para que os registros continuassem chegando e marcou a decisão como exceção temporária. Meses depois, a pergunta decisiva não era se a exceção existia, mas quais mensagens realmente atravessaram aquele caminho.

A RFC 9662 foi escrita para uma transição desse tipo. Ela atualiza os mapeamentos seguros de syslog e acrescenta TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ao conjunto obrigatório de implementação, com preferência sobre RSA/CBC. Ao mesmo tempo, preserva a opção anterior para evitar que a modernização rompa a entrega antes da atualização de dispositivos.

Essa é uma decisão de interoperabilidade, não um recibo operacional. Implementar não é habilitar; habilitar não é oferecer; oferecer não é negociar; negociar não é enviar; enviar não é ser aceito; ser aceito não é permanecer pesquisável.

A ponte legada precisa mostrar tráfego e saída

Uma exceção útil identifica classe do equipamento, versão, endpoint, transporte, coletor, suite, peer permitido, motivo, controles compensatórios, responsável, aprovação, validade e teste de upgrade. Também registra cada seleção real da suite antiga por época de conexão.

Sem uso observado, duas decisões opostas parecem igualmente razoáveis. Uma exceção nunca selecionada pode ser retirada. Uma exceção selecionada continuamente revela dependência e prioridade de migração. Um arquivo de configuração sozinho não responde a nenhuma das duas.

O registro TLS da IANA coordena identificadores e estados. Ele não vê a política local nem um handshake. O texto, o produto, a configuração, a oferta e a escolha viva pertencem a camadas diferentes.

TLS e DTLS exigem provas próprias

No mapeamento TLS, TLS 1.2 permanece obrigatório de implementar. TLS 1.3 deve ser suportado quando viável e preferido se implementado. No mapeamento DTLS, DTLS 1.0 não pode ser usado, DTLS 1.2 deve ser usado e DTLS 1.3 deve ser suportado e preferido quando implementado.

A RFC 8996 e a RFC 9325 dão o contexto de segurança. Mas um campo que diga apenas “1.2” não basta. TLS 1.2 e DTLS 1.2 têm superfícies diferentes de perda, ordem e confirmação. O mesmo vale para TLS 1.3 e DTLS 1.3.

Um datagrama protegido pode desaparecer sem confirmação da aplicação. Uma conexão TLS longa pode permanecer aberta enquanto a fila para de escoar. O recibo deve registrar transporte e época de conexão para cada evento.

Recusar early data é necessário, mas não suficiente

A RFC 9662 proíbe early data do TLS 1.3 porque o protocolo syslog não oferece proteção contra replay. O controle reduz a ambiguidade de eventos repetidos no 0-RTT. Ele não fornece semântica exactly-once ao caminho normal.

Depois do handshake, ainda pode haver duplicação na origem, descarte de fila, perda na reconexão, rejeição do coletor, falha de armazenamento, roteamento para o índice errado ou expiração antecipada. Testar o bloqueio de 0-RTT e testar um evento canário de ponta a ponta são controles independentes.

Autenticar o peer não comprova a retenção

O modelo de certificados da RFC 5280 ajuda a validar a cadeia. A operação ainda precisa conferir a âncora esperada, a identidade de referência e a autorização. Mesmo quando tudo isso está correto, a evidência termina no canal.

Para o evento, registre um identificador estável, criação, entrada e saída de fila, tentativa de envio, época de conexão, versão e suite negociadas, retomada e early-data state, resultado do transporte, identificador de aceite do coletor, escrita durável, índice, retenção e releitura segura.

Preserve os negativos: ausência de suite comum, versão proibida, falha de certificado ou identidade, peer não autorizado, tentativa de early data, quebra, fila cheia, perda de datagrama, rejeição, falha de escrita e busca vazia. Uma luz única de “syslog seguro” apaga a custódia.

O padrão termina onde a observação começa

O texto canônico, a fonte XML, a página informativa, as erratas e o histórico estabelecem o conteúdo normativo. Eles não observam um evento em produção.

Comece a prova pela pergunta final: o investigador autorizado encontrou o evento na janela prometida? Ligue essa leitura ao objeto durável e ao aceite; depois ao envio, à conexão, à fila e à política. Assim, a equipe de criptografia não usa o handshake para falar pelo armazenamento, e a equipe de armazenamento não usa a saúde do índice para falar pela origem.

Heng Lu oferece a proporção institucional correta. Minimum Initial Specification mantém pequeno o piso compartilhado e explícita a decisão local. Reality Layers impede que um rótulo normativo herde autoridade de um resultado real. Running-Code Primacy coloca a prova no sistema que negociou, transportou, aceitou e reteve.

A ponte legada pode ser a decisão correta por um período. A obrigação de liderança é torná-la visível, limitada e mensurável, sem confundir o funcionamento do canal com a sobrevivência do registro.

Fontes