Hi, here are comments I mistakenly sent to a thread about another dprive last call. 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. 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. thanks, Rob
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
