> On 23 Dec 2019, at 22:12, Rob Sayre <sayrer@xxxxxxxxx> wrote: > > Hi, here are comments I mistakenly sent to a thread about another dprive last call. I took the liberty of removing Stephen, Ben and secdir from the cc list and modifying the subject as I believe this is a general review of the document not one specific to the issues raised by the secdir review. Please correct me if I’m wrong. > Summary: the section about "DoH Specific Considerations" is highly questionable, and seems like advocacy rather than a representation of IETF consensus. > > ---- > > Hi, > > I found two issues with [this draft]. The document mentions unattributed "concerns" in a few places.. That doesn't seem like helpful content, but I can't say that such "concerns" and rampant use of the passive voice are uncommon in today's IETF. I would suggest replacing ‘concerns' with ‘considerations', given that the title of the document is DNS Privacy Considerations. > > 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, ones with PKI and PGP are clearly out of scope for this document. Sara. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
