> On 31 Jan 2020, at 10:45, Mirja Kühlewind via Datatracker <[email protected]> 
> wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-dprive-bcp-op-08: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> A couple of small comments/questions:
> 
> 1) RFC2119/RFC8174 disclaimer is present in section 4, however, it does seem 
> to
> be the case that normative language is used. I would recommend to actually use
> normative language in this doc!
> 

There is one key instance of a SHOULD in section 5 which ripples through the 
entire document because it covers the requirement for the various mitigations. 

“This document does not specify policy - only best practice, however
   for DNS Privacy services to be considered compliant with these best
   practice guidelines they SHOULD implement (where appropriate) all:"

It is easy to miss though…...

> 
> 2) Can you actually provide references for the techniques listed in Table 1?

Do you mean the Categorization/Properties or the actual techniques listed? The 
latter are described in detail in Appendix B.

> 
> 3) Sec 5.1.3.1:
> “A DNS-over-TLS privacy service on both port 853 and 443.  This
>      practice may not be possible if e.g. the operator deploys DoH on
>      the same IP address.”
> Isn’t 443 basically DoH?

No, this means using the DNS-over-TLS protocol, just on port 443 by prior 
agreement between client and server (RFC7858 describes this). No HTTPS involved.

> Why would you deploy DoT over 853?
> Is that a common practice? Sorry if I miss something…

Port 853 is the IANA assigned port for DoT. Before DoH was a thing, it was 
suggested that running DoT on 443 would prevent issues where port 853 might be 
blocked - several early DoT services did this. 

Best regards

Sara. 

_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to