Time for a bis document ?
On Tue, 31 Mar 2026, 23:26 Matthias Gierlings, <matthias.gierlings= [email protected]> wrote: > Dear DNSOP-WG Members, > > we are a team of researchers at Ruhr-University Bochum and University > of Wuppertal who uncovered vulnerabilities in the DNS Queries over > HTTPS Standard (RFC 8484)[1]. Those vulnerabilities enable exploits > against DoH services that inject malicious, attacker controlled > content into web-origins of victim sites. This novel class of > Cross-Site-Scripting (XSS) attacks is called XSS-over-DoH and > consists of: > > (1) *Direct XSS over DoH*, which directly delivers malicious markup > containing JavaScript, that is subsequently rendered and executed > in the origin of a vulnerable DoH server. > (2) *CSP-Bypass over DoH* bypasses strong CSPs > (Content-Security-Policies) and defeats robust browser protection > mechanisms designed to suppress script execution in the face of > markup injection. > > Please refer to the attached document for further details on both > attacks, the associated techniques and their impact on victims. > > The current version RFC 8484 has various issues, e.g.: > > - RFC 8484, p. 10, §5.4. "Content Negotiation" explicitly permits > media types other than "application/dns-message" to be used for DoH > communication. This enables (1) Direct-XSS-over-DoH. Further §5.4. > as well as §9. "Security Considerations" miss to highlight the > dangers of using other media types especially those that are > renderable by clients. > > - Even in cases where services set the more common media type > "application/dns-message" MIME-sniffing in browsers causes them > to treat JavaScript payloads as script code despite conflicting > information present in the "Content-Type: > application/dns-message" header. This enables (2) CSP-Bypass over > DoH. > > - From RFC 8484, p. 12 8.1. On the Wire: > > DNS over TLS [RFC7858] provides similar protections, while direct > > UDP- and TCP-based transports are vulnerable to this class of > > attack An experimental effort to offer guidance on choosing the > > padding length can be found in [RFC8467]. > > > Additionally, the use of the HTTPS default port 443 and the > > ability to mix DoH traffic with other HTTPS traffic on the same > > connection can deter unprivileged on-path devices from > > interfering with DNS operations and make DNS traffic analysis > > more difficult. > > This section suggests that, due to the use of TLS, DoH achieves a > protection level similar to that of DoT. However it fails to > recognize the severe consequences that result from protocol > confusion between HTTP(S) and DoH (please refer to the attached > document for details). This confusion is only possible because > DoH reuses the HTTP(S) well-known port and the HTTP(S) message format > to encapsulate DNS. With DNS over TLS (DoT) a confusion is impossible > because in default configurations the web-origin of DoT services is > different from that of a website using the same domain due to the use > of a different service port (853). > > We would like to open the discussion on how to improve the current > DoH standard and propose to thoroughly cover the aforementioned > issues in the section "Security Considerations". We also suggest a > countermeasure called "Explicit Content Type Negotiation (ECTN)" to > become part of the standard. ECTN prevents confusion of HTTP(S) and > DoH communication contexts at the server level and stops any > attacker controlled content from being served in context of plain > HTTP(S) communication. A detailed description of ECTN and secondary > countermeasures is also part of the attached document. > > We are looking forward to work with you towards improving RFC 8484 > "DNS-Queries over HTTPS" and make the protocol more secure for service > operators and its users. We are happy to help clarifying in further > or upcoming questions. > > Kind regards > > Matthias Gierlings > > [1] https://datatracker.ietf.org/doc/html/rfc8484 > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
