> On 23 Dec 2019, at 22:12, Rob Sayre <[email protected]> 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. 
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to