Resumo

  • Em 3 de setembro de 2026, o IESG aprovou como Proposed Standard o perfil TLS/DTLS 1.3 para Internet das Coisas. O documento trata de restrições e dispositivos duradouros, mas não transforma conformidade em prova de que uma frota trocou sua autoridade de confiança.
  • Toda economia de bytes deve vir acompanhada de um mapa da dependência criada. A transição de âncoras também precisa ligar, por equipamento, autorização, gravação persistente, caminho aceito, último uso antigo, limite de retorno e recibo da aplicação.

O anúncio do IESG aprovou o draft-ietf-uta-tls13-iot-profile-25. O Datatracker registra a versão 25 com anúncio enviado; na consulta, ainda não havia número RFC final. O texto aprovado acompanha a RFC 7925, referente a TLS/DTLS 1.2 em ambientes restritos, e atualiza requisitos de X.509 e de conjuntos criptográficos.

O documento parte de uma realidade que o painel de produto costuma esconder. Equipamentos ficam em campo durante anos; algoritmos, CAs, fabricantes e prestadores mudam mais depressa. Uma âncora estática durante toda a vida útil torna rotação, troca de fabricante e resposta a incidentes mais difíceis.

A raiz enviada pelo próprio servidor na mensagem Certificate não ganha confiança por estar dentro do handshake que ainda será validado. A preferência é provisionar âncoras fora desse diálogo e omitir a raiz da cadeia transmitida. Portanto, instalar confiança é uma operação de autoridade local, não uma consequência automática da negociação.

O custo sai do fio e reaparece na arquitetura

Se o requisito normal, próximo de 18 KB de buffers de processamento, não for aceitável, o Record Size Limit da RFC 8449 permite anunciar o maior registro que o par aceita. O valor não mede memória total, flash, energia nem tempo de validação.

A retomada de sessão da RFC 9846 evita repetir parte da autenticação por certificado. Quantidade, duração e reutilização de tickets, porém, transferem decisões para o estado do servidor, privacidade e controle de replay. O perfil IoT não autoriza sozinho 0-RTT para CoAP, MQTT ou outra aplicação sem regras próprias.

A compressão de certificados, informações em cache e URLs de certificados também diminuem bytes. Em troca, podem exigir cache coerente, serviço de recuperação disponível ou identificador estável. A pergunta de governança não é apenas “quanto caiu o handshake?”, mas “qual componente passou a poder interromper ou redefinir a confiança?”.

Três credenciais deslocam a custódia de formas diferentes

O perfil admite X.509, chaves públicas brutas e PSKs externas; não impõe uma opção universal.

Em X.509, âncora, CAs intermediárias e certificado final têm funções separadas. A raw public key da RFC 7250 reduz a estrutura no protocolo, mas ainda requer uma associação protegida entre a chave e a identidade esperada. Certificado X.509 autoassinado continua sendo X.509.

Nas PSKs externas, a custódia se concentra no segredo. A RFC 9257 detalha riscos de entropia, identidade e implantação. A RFC 9258 liga a importação ao KDF e ao contexto de hash de TLS 1.3. Ainda é necessário saber quem criou, quem copiou, quais dispositivos compartilham, quando gira e para qual serviço vale.

Por isso, um registro “TLS ativo” não é suficiente. Cada modalidade produz recibos e possibilidades de abuso diferentes.

Distribuído, instalado e utilizado são três estados

Atualização segura de firmware pode distribuir novas âncoras. A arquitetura SUIT da RFC 9019 distingue autor, distribuidor, dispositivo e relações de confiança. A entrega, contudo, vem antes da validação do pacote, gravação durável, ativação, reinicialização, releitura do repositório e conexão efetiva pelo novo caminho.

O escopo também não deve crescer por suposição. Distribuir uma âncora em firmware não renova automaticamente certificados de entidade final nem de CA subordinada. A RFC 7030 fornece EST para inscrição e obtenção de certificados de CA; suporte e uso bem-sucedido continuam fatos de cada implantação.

Um índice de 98% não revela onde ficaram os 2%. Um sensor descartável e a única válvula remota têm consequências distintas. É preciso guardar identidade, geração física e lógica, impressões das âncoras, resultado, ativação, último contato e dono da exceção.

A ponte de certificados precisa de uma saída

Durante uma rotação de CA, a extensão certificate_authorities ajuda o servidor a selecionar uma cadeia compatível com o que o par declara aceitar. Os certificados transitórios newWithOld e oldWithNew descritos na RFC 9810 criam passagem entre gerações. Eles não substituem o provisionamento fora de banda da nova âncora.

Se o serviço mantiver caminhos compatíveis com a autoridade antiga, equipamentos adormecidos continuam conectando e o gráfico permanece verde. A autoridade antiga também continua operacional. A ponte vira permanência quando não há evidência de saída.

Remover cedo demais traz o dano oposto: um dispositivo isolado talvez perca o único canal autenticado para receber a correção. A data de retirada deve depender do estado observado das coortes e de uma rota de recuperação, não de uma campanha encerrada no servidor.

O livro-razão da geração de confiança

Por dispositivo, registrar gerações de hardware, firmware e secure boot; raiz de atualização; modo de credencial; impressões, papéis e políticas das âncoras aceitas. Cada mudança deixa recibos separados de autorização, entrega, verificação, escrita persistente, ativação, reinício e releitura.

Em seguida, registrar o que o serviço apresentou e o equipamento aceitou: certificado final, cadeia intermediária, geração da âncora, protocolo negociado e instante. O recibo da aplicação é outra prova. Um handshake autentica um par por um caminho; não comprova que um comando foi autorizado, confirmado ou executado fisicamente.

A disciplina de camadas de realidade de Lu Heng separa Proposed Standard, configuração, evento executado e resultado. Running-Code Primacy coloca o estado observado acima do material de produto. A especificação inicial mínima com decisão futura localizada permite uma base interoperável sem impor uma única CA ou topologia.

Fontes