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
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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
