On Thu, Jan 9, 2020 at 10:02 AM Sara Dickinson <[email protected]> wrote:
> > > 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]> 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. > [Citation needed] -Ekr > > 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 > > > 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 >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
