>
> Secondly, I found the entire section "3.5.1.5.2. DoH Specific Considerations" to be objectionable, and recommend removing it. It mentions many concerns that are better covered in RFC 8484 and/or HTTP RFCs, and contrasts DoH with DoT in ways that are specious. Both TLS and HTTP allow extension fields and metadata, so there's nothing unique to DoH here (source: I've implemented DoH and ESNI clients). The entire section amounts to a description of fields that privacy conscious DoH clients /might/ send if they were poorly implemented. But it seems strange to stop there.. Implementation quality ratholes can go on for a while: for example, the document doesn't mention the numerous problems with today's TLS, PKI, and BGP infrastructure that apply to both DoT and DoH.
As mentioned since this document is an analysis of the privacy considerations of actually _using_ DNS (not just the protocol definitions) then privacy considerations raised by poor implementations seem entirely in scope. The document does also discuss such issues with TLS,
The document contains the text:
"DoT, for example, would normally contain no client identifiers above the TLS layer and a resolver would see only a stream of DNS query payloads originating within one or more connections from a client IP address. Whereas if DoH clients commonly include several headers in a DNS message'
Doesn't this just mean "if the DoT client is a good implementation, and the DoH client is not...” ?
It means a standards compliant DoT implementation will have no client identifiers, a standards compliant DoH implementation is free to (and likely) to include them.
I think the Section 8.2 of RFC8484 states this problem better. Why do we need this section?
As others have mentioned - this document gives an overall discussion of privacy across all DNS protocols, RFC8484 is focussed on the DoH specific aspects. ones with PKI and PGP are clearly out of scope for this document.
I didn't mention PGP--I was talking about misrouting (BGP). I disagree that they are out of scope. Most of the larger TLS use cases rely on PKI.
I meant BGP - it was a typo. Section 2 currently states:
“The privacy risks associated with the use of other protocols, e.g., unencrypted TLS SNI extensions or HTTPS destination IP address fingerprinting are not considered here.”
Sara.
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
