On Tue, Jan 7, 2020 at 10:35 AM Sara Dickinson <sara@xxxxxxxxxxx> 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 querypayloads 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?
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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
