On Tue, Jan 7, 2020 at 10:35 AM Sara Dickinson <[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..." ? 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 > 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. thanks, Rob
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
