Resumo

  • Em 3 de setembro de 2026, o IESG aprovou a revisão 25 de TLS/DTLS 1.3 Profiles for the Internet of Things como Proposed Standard; o anúncio ainda não informou o número RFC final.
  • O documento acompanha a RFC 7925 e atualiza apenas o perfil de certificados X.509 e os requisitos de conjuntos criptográficos. Instalações antigas com TLS/DTLS 1.2 continuam no mundo real.
  • A própria revisão fixa o limite central: compatibilidade de protocolo é base necessária, porém insuficiente para interoperabilidade de autenticação e autorização.
  • Certificados, chaves públicas brutas e PSKs externos distribuem identidade, provisionamento e ciclo de vida de modos diferentes. Nenhum handshake bem-sucedido concede sozinho uma permissão operacional.
  • Operadores precisam de um recibo versionado que una credencial, par esperado, regra local, âncora, idade da sessão, reautenticação, erro e reversão, sem publicar segredos.

O acordo comum termina antes da ação

A Protocol Action resolve uma parte concreta da coordenação. O trabalho da Using TLS in Applications estabelece, para dispositivos restritos, requisitos comuns de credenciais, extensões, alertas, retomada de sessão, sigilo futuro, temporizadores, tamanhos de registro, certificados e conjuntos criptográficos em TLS/DTLS 1.3.

Esse chão evita que duas implementações retirem recursos diferentes e ainda chamem o resultado de compatível. Um fabricante e um serviço podem testar as mesmas extensões e campos. Mas a revisão 25 rejeita um salto de autoridade: entender o mesmo protocolo não significa interpretar igualmente a identidade ou autorizar as mesmas operações.

A criptografia verifica posse de uma chave no contexto negociado. O operador precisa ligar essa chave ao equipamento previsto, a um papel de aplicação e a uma política vigente. A IETF aprovou o documento; não aprovou a lista de permissões de uma fábrica, hospital ou rede de sensores.

O estado documental também tem bordas. Trata-se de Proposed Standard aprovado, ainda sem número RFC definitivo no anúncio e sujeito ao trabalho editorial antes da publicação. Não é Internet Standard nem certificado de produto. Preservar esses estados permite usar a decisão sem transformá-la em evidência que ela não contém.

A atualização da RFC 7925 é intencionalmente estreita. Ela cobre certificado e ciphersuite, mantendo o perfil 1.2 relevante para sistemas herdados. Uma frota industrial pode levar anos para migrar. O controle correto identifica a geração de cada grupo, em vez de declarar que a aprovação atual mudou todos os dispositivos antigos.

Três credenciais não produzem a mesma identidade

O perfil admite certificados, raw public keys e PSKs externos. Não escolhe uma forma universal, porque segurança, custo, capacidade e operação variam.

No caminho X.509, uma cadeia liga a chave a um identificador certificado. A distinção entre IDevID de fabricação e LDevID operacional mostra que o vínculo possui etapas. A identidade inicial serve normalmente ao bootstrap; o proprietário ou operador fornece a credencial do domínio de produção. Deixar a primeira como autorização permanente por conveniência mudaria sua função sem registrar a decisão.

A chave pública bruta reduz o peso do certificado, mas precisa de outro vínculo com o par esperado. Se SNI não for enviado porque o sistema usa chave fixada, certificado próprio, endereço configurado ou identidade PSK, a aplicação continua obrigada a saber quem aquela prova representa. Do contrário, valida a chave certa para o serviço errado.

No PSK externo, identidade, entropia, escopo, separação entre versões e troca são definidos fora do handshake. O perfil recomenda (EC)DHE para obter forward secrecy. PSK-only é aceitável apenas quando a perda dessa propriedade foi explicitamente aceita no contexto da implantação. Essa aceitação precisa de dono, alcance e prazo.

SNI seleciona um contexto de servidor; ALPN reduz confusão entre protocolos. Nenhum dos dois autoriza uma ação. O texto deixa a decisão para as credenciais autenticadas combinadas com política local.

A revogação sobe para o operador

Dispositivos restritos muitas vezes não consultam OCSP nem CRL durante o handshake. A revisão 25 descreve a alternativa: certificados operacionais de curta duração, onboarding automatizado e gestão capaz de distribuí-los novamente. A responsabilidade é deslocada, não eliminada.

Uma credencial substituída também não derruba automaticamente sessões longas. TLS não obriga verificação contínua depois que a conexão foi criada. Quando isso é exigido, a aplicação precisa solicitar nova autenticação ou encerrar e refazer a sessão. Autenticação mútua posterior ao handshake requer suporte adicional do protocolo de aplicação.

Portanto, “novo certificado instalado” e “última sessão antiga encerrada” são recibos distintos. Entre eles vive o risco que o operador aceitou. Um painel de validade que ignora sessões não mede a retirada da autoridade anterior.

Âncoras de confiança vivem ainda mais. Um equipamento pode atravessar mudança de CA, fabricante, algoritmo ou resposta a incidente. Firmware e protocolos de certificados transportam uma âncora nova, mas transporte não prova instalação, seleção ou aposentadoria da anterior. O inventário deve manter cada estado e os dispositivos sem contato no denominador.

Economizar pacote transfere custos

No exemplo mínimo do documento, dois certificados ECC representam cerca de 40% da carga do handshake TLS 1.3 com autenticação mútua e sem CA subordinada. Cadeias rasas, compressão, cache e retomada ajudam bastante em rádio e bateria.

Cada economia cria outra decisão. Quantidade, vida e reutilização de tickets equilibram computação e banda contra estado do servidor, replay e privacidade. Recuperar certificados externamente acrescenta DNS ou diretórios e pode expor identificadores estáveis. Cache exige invalidação. Um pacote menor pode depender de uma infraestrutura maior.

0-RTT demonstra a fronteira sem ambiguidade. Um protocolo de aplicação não pode usá-lo sem perfil próprio que diga quais mensagens são seguras e como voltar a 1-RTT. Na revisão 25, CoAP e MQTT não tinham esse perfil; este texto não habilita 0-RTT para eles. Poder enviar cedo não é autorização para enviar cedo.

O tratamento de erros completa o quadro. Um equipamento desacompanhado não pode perguntar se deve tentar outra vez, trocar a credencial ou parar. A aplicação deve ligar cada alerta relevante a repetição, alternativa, modo degradado ou estado seguro. A biblioteca oferece o fato; a política escolhe a consequência.

O recibo da fronteira de autorização

O registro começa por versão do perfil e build da implementação. Depois nomeia modo de credencial, referência estável, identidade esperada, método de vínculo, protocolo e papel, versão da política e classe de ação autorizada ou recusada.

O bloco de ciclo de vida registra geração da âncora, certificado ou PSK, canal de entrega, ativação observada, vencimento e substituição. O bloco de sessão separa handshake completo e retomado, informa geração do ticket, início, última reautenticação e idade máxima. Exceção de forward secrecy recebe responsável e data final.

O bloco de segurança liga falhas a nova tentativa, caminho alternativo, degradação ou parada segura. 0-RTT fica marcado como desativado ou, diante de perfil futuro, limitado a tipos de mensagem e estado anti-replay. Correções são anexadas, não sobrescritas, pois sessões antigas nasceram sob regras antigas.

Nada exige publicar chaves, certificados completos, nomes internos, dados pessoais ou topologia precisa. Versão, coorte, tempo, resultado, exceção e autoridade decisora formam prova suficiente para a superfície pública.

A Nota 64 de Heng Lu entra só como lente editorial: o acordo comum deve ser mínimo, determinístico e verificável localmente. Ela não prova um caso de IoT. Aqui, impede tanto uma política universal de acesso escrita pela IETF quanto uma escolha local invisível que toma emprestado o prestígio do padrão.

O que a aprovação não prova

Nenhuma fonte analisada certifica produto, auditoria de frota ou incidente. O IESG não escolheu CA, PSK, tabela de permissões, resposta a alerta ou estado seguro de um operador.

O perfil também não é pós-quântico. Suas recomendações normativas usam criptografia clássica; a seção PQC é informativa e não acrescenta requisito. Vida útil longa torna a migração urgente, não concluída.

O texto não diz que nenhum dispositivo restrito pode consultar OCSP ou CRL. Ele descreve um limite comum e recomenda avaliação caso a caso. Equipamentos capazes podem adotar controles diferentes.

O ganho da aprovação é mais preciso: a IETF reduz incompatibilidades evitáveis. A entidade que permite a ação continua dona da decisão e da evidência que a sustenta.

Fontes

  1. IESG — Protocol Action do perfil IoT
  2. IETF — revisão 25 aprovada
  3. RFC 9846 — TLS 1.3
  4. RFC 9147 — DTLS 1.3
  5. RFC 7925 — perfis TLS/DTLS para IoT
  6. RFC 5280 — perfil PKI X.509
  7. RFC 9257 — PSKs externos
  8. RFC 9258 — importação de PSKs externos
  9. RFC 9019 — atualização de firmware IoT
  10. RFC 8995 — BRSKI
  11. RFC 9525 — identidade de serviço TLS
  12. RFC 9325 — uso seguro de TLS e DTLS
  13. Heng Lu — Minimum Initial Specification