Resumo

  • A RFC 9761 acrescenta ao MUD um perfil declarado de TLS e DTLS para dispositivos IoT; ele descreve comportamento esperado, não atesta o software em execução.
  • Um valor conhecido e não declarado pode motivar alerta ou bloqueio. Um valor que o firewall não conhece não deve ser bloqueado só por ser desconhecido; se o perfil o declara, a defasagem está no fiscal.
  • TLS 1.3, ECH e DNS criptografado reduzem o que um observador passivo consegue provar. Um proxy recupera visibilidade criando outro limite de privacidade e confiança.

O relatório de conformidade culpava o sensor. A captura dizia algo mais modesto: o ClientHello trazia um número que não estava no perfil arquivado, e o analisador do firewall não sabia associá-lo a parâmetro algum.

É justamente aí que a RFC 9761 separa os casos. Se o firewall reconhece um parâmetro ausente do perfil MUD, ele pode tratar a ocorrência como uso inesperado. Se nem o perfil nem o firewall conhecem o valor, a conduta correta é não bloquear a sessão apenas por esse desconhecimento. Uma extensão legítima pode ter chegado antes da atualização do intermediário.

O fabricante fornece referência, não comando

A RFC 8520 parte de equipamentos com finalidade limitada. Um fabricante descreve os destinos e padrões necessários, e a rede local converte essa Manufacturer Usage Description em política. A origem da descrição não ganha autoridade sobre todas as consequências locais.

A RFC 9761 estende as ACLs da RFC 8519 com versões TLS/DTLS, cifras, extensões, grupos, assinaturas, modos PSK, ALPN, âncoras de confiança, autoridades aceitáveis e compressão de certificados. A comparação passa a captar uma mudança de software que o simples destino na porta 443 esconderia.

Ainda assim, o perfil fala do esperado para um modelo. O pacote fala de uma negociação. O firewall fala do seu próprio repertório. Nenhum dos três lê diretamente o estado interno do dispositivo.

Quatro resultados exigem quatro donos

Valor no perfil e reconhecido pelo firewall: compatível com a expectativa, mas não necessariamente benigno. Malware pode imitar listas legítimas.

Valor fora do perfil e reconhecido: desvio com significado conhecido. Pode ser software não autorizado, comprometimento, atualização legítima anterior ao perfil ou vínculo errado de modelo. Ação local é possível, desde que preserve o valor, as versões e a regra responsável.

Valor no perfil e desconhecido pelo firewall: o perfil avançou primeiro. O analisador deve ignorar o item, permitir conforme as demais condições e alertar fornecedor e proprietário. Valor fora do perfil e também desconhecido: a incerteza é maior, mas não autoriza bloqueio automático. A RFC 8446 exige que intermediários TLS 1.3 tolerem suites, extensões e parâmetros não reconhecidos.

GREASE impede que a lista antiga vire parede

A RFC 8701 faz clientes anunciarem valores reservados para testar continuamente a extensibilidade. A RFC 9761 proíbe inserir GREASE no perfil MUD. Marcar essas aparições como hostis destruiria o teste feito para encontrar implementações rígidas.

Os registros da IANA para parâmetros TLS, parâmetros YANG e MUD mantêm nomes e módulos compartilhados. Registro não instala suporte. A trilha deve mostrar qual revisão existia e qual módulo o firewall realmente carregou.

Bloquear toda novidade transfere poder ao fornecedor mais lento. Ele passa a decidir quando um protocolo aberto pode evoluir. Permitir e alertar mantém o operador informado sem converter atraso de manutenção em veto universal.

A versão nova esconde parte do aperto de mão

TLS e DTLS 1.2 expõem ClientHello, ServerHello e Certificate. TLS 1.3 cifra quase tudo depois do ClientHello; o DTLS 1.3 reduz a visibilidade da mesma forma. Um firewall passivo ainda compara algumas ofertas, mas não enxerga o certificado do servidor nem o perfil completo.

ECH pode ocultar SNI e outros campos. DNS criptografado pode ocultar a consulta. Se o dispositivo usa um resolvedor que a rede não designou, a fiscalização MUD baseada em nomes perde seu ponto de controle. DDR e DNR permitem designar resolvedores criptografados, mas a adesão do dispositivo continua sendo um fato separado.

Um proxy TLS amplia a inspeção encerrando a proteção. A RFC 9761 restringe essa prática a equipamentos pertencentes e administrados pela empresa, exige conformidade com suas regras de segurança e privacidade e desaconselha o proxy sempre que possível. O motivo é estrutural: o proxy vira ponto de confiança, move a validação de certificado e pode acessar dados pessoais ou de saúde.

A RFC 9325 orienta a identificação de escolhas criptográficas fracas. A RFC 8613 mostra, com OSCORE, que objetos de aplicação podem continuar protegidos ponta a ponta mesmo quando há controle em outra camada. São alternativas a avaliar, não autorização automática para descriptografar.

Coincidência é um sinal negativo, não identidade

Software malicioso pode copiar um perfil legítimo. Diferenças entre modelos, certificados, destinos e cadência de atualização tornam a tarefa difícil, não impossível. O resultado “conforme” apenas diz que aquela diferença não apareceu.

Uma prova defensável liga identidade e modelo observados, URL e hash do MUD, assinatura, revisão, firmware, fluxo, código bruto do parâmetro, resultado de perfil, versão do analisador, contexto DNS/IP, ECH, proxy, decisão e verificação no endpoint. is-supported=false informa o fim do suporte do fabricante; não prova defeito atual.

A separação entre camadas de realidade impede que documento e execução se confundam. A primazia do código em operação exige conferir as versões carregadas. Uma especificação inicial mínima com decisão futura localizada coordena significados, sem entregar ao padrão ou ao fabricante a decisão de cada rede.

O perfil serve melhor como sensor calibrado. Ele mostra tanto a possível anomalia do dispositivo quanto a possível obsolescência de quem o vigia.