Resumo

  • Em 5 de setembro, a revisão 01 de DNS and mDNS Discovery for MOQT adicionou normalização de URI e correspondência detalhada de certificados X.509. A revisão 02 alterou apenas o link do repositório-fonte.
  • Quando SVCB ou SRV direciona a conexão a outro host, o cliente continua validando a autoridade da URI moqt original. O caminho mDNS ainda não define como um serviço navegado obtém essa identidade de referência ou permissão para anunciar _moqt._udp; a seção de segurança permanece TODO.

Em um estúdio temporário, configurar cada tela com um relay pode consumir mais tempo que montar a rede. O mDNS promete eliminar essa etapa: PTR lista a instância, SRV informa host e porta, TXT declara alpn=moqt. A oferta fica utilizável em segundos. Usável, porém, não significa autorizada pelo produtor do evento.

O registro no Datatracker data a versão atual de 5 de setembro de 2026. O nome é de um Internet-Draft individual, sem stream IETF e sem intended standard level na ficha. A capa diz que o destino pretendido é Standards Track e encaminha a discussão à lista Media over QUIC. Isso não equivale a adoção pelo grupo de trabalho, consenso ou aprovação.

O histórico delimita a notícia. A revisão 00, de agosto, já apresentava SVCB, HTTPS, SRV e DNS-SD local. A revisão 01 acrescentou o contrato de identidade. A revisão 02, no mesmo dia, só corrigiu o endereço do código. O anúncio I-D registra uma proposta em evolução, não um recurso disponível em produtos.

Indireção escolhe o caminho, não o principal

Para MOQT nativo sobre QUIC, a proposta usa SVCB. Para WebTransport, usa HTTPS. SRV é a alternativa com menos parâmetros, pois entrega alvo e porta, mas não ALPN. Um registro aproveitável pode, portanto, mandar o socket para um host diferente daquele escrito na URI.

A revisão 01 impede que esse host assuma a identidade do serviço. SNI e validação do certificado usam o host da URI moqt original. O alvo resolvido é um local de conexão intermediário. O RFC 9460 estabelece o mesmo limite para SVCB/HTTPS: a alternativa não muda a autoridade da origem.

O RFC 9525 explica por que isso é necessário. Um reference identifier deve nascer de uma entrada configurada ou obtida em contexto seguro. Nomes intermediários encontrados durante a resolução não viram identidades de referência sem um processo específico de autenticação.

O novo texto também reduz ambiguidades de comparação. Normaliza caixa e percent-encoding sob o RFC 3986, adiciona a porta 443 quando ausente, remove o ponto final e converte nomes internacionais segundo o RFC 5890. Proíbe wildcard e CN-ID. Admite formas subjectAltName de DNS, IP, URI e o SRVName do RFC 4985.

É uma melhoria operacional: o DNS não recebe poder para decidir simultaneamente rota e identidade. Mas ela depende de haver uma URI original antes da resolução. A navegação mDNS pode começar por uma lista de instâncias sem essa origem previamente autenticada.

Origem local é uma prova topológica estreita

No mDNS, o relay publica PTR, SRV e TXT em .local. O RFC 6762 usa verificações de endereço e TTL para evitar que uma resposta remota pareça local. Isso só prova proximidade de enlace. Um dispositivo hostil já conectado passa pelo mesmo limite topológico.

O RFC descreve a resolução de conflitos como cooperação sem autoridade central e recomenda proteção criptográfica quando nem todos os participantes são confiáveis. Também avisa que nomes .local não carregam autoridade global. O RFC 6763 define a estrutura DNS-SD e recomenda DNSSEC quando a autenticidade é importante; não atribui representação institucional ao anunciante.

Na proposta MOQT, um ALPN reconhecido elimina uma instância incompatível, mas não identifica seu operador. As Security Considerations atuais contêm somente TODO. Falta ainda dizer como a instância navegada produz a URI original para a verificação X.509 e qual política permite que o anunciante fale por ela.

Configuração prévia, identidade fixada, domínio assinado ou confirmação explícita podem preencher o espaço em uma implementação. A ausência no draft não prova ataque nem vulnerabilidade. Ela prova apenas que a descoberta deve permanecer uma lista de candidatos, não uma decisão de confiança.

A autorização continua depois do handshake

O MOQT Transport 20 usa QUIC ou WebTransport para proteger o transporte. Direitos de assinatura, publicação e namespace continuam sendo definidos pelo aplicativo ou pelo framework de autorização. Certificado válido, namespace permitido, sessão estabelecida e mídia correta são fatos independentes.

Uma trilha responsável registra anúncio, interface, alvo, URI original, identidade de referência, resultado X.509, regra local, autorização do conteúdo, sessão e objeto recebido. Agregar tudo como “relay encontrado” elimina justamente a atribuição necessária quando duas ofertas aparecem.

A especificação inicial mínima de Heng Lu favorece o invariante estreito que o draft já encontrou: indireção não muda autoridade. As camadas da realidade mantêm separados anúncio, identidade, autorização e efeito. A primazia do código em execução exige observar qual nome e política o cliente real aplicou.

Fontes

  1. Registro IETF Datatracker
  2. MOQT Discovery, revisão 02
  3. Revisão 01
  4. Revisão 00
  5. Anúncio da revisão 02
  6. MOQT Transport, revisão 20
  7. RFC 9460: SVCB e HTTPS
  8. RFC 6762: Multicast DNS
  9. RFC 6763: DNS-Based Service Discovery
  10. RFC 9525: identidade de serviço em TLS
  11. RFC 4985: SRVName
  12. RFC 3986: sintaxe de URI
  13. RFC 5890: IDNA
  14. Heng Lu: especificação inicial mínima
  15. Heng Lu: camadas da realidade
  16. Heng Lu: primazia do código em execução