> On 7 Jan 2020, at 22:08, Rob Sayre <[email protected]> wrote: > > On Tue, Jan 7, 2020 at 10:35 AM Sara Dickinson <[email protected] > <mailto:[email protected]>> wrote: > > > > > 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? > > https://tools.ietf.org/html/rfc8484#section-8.2 > <https://tools.ietf.org/html/rfc8484#section-8.2> 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.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
