Re: [dns-privacy] Mirja Kühlewind's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Hi Sara,

Thanks for you replies and edits.

I personally think it would be better to use normative language thought the whole document for each requirement or just not at all. But that is really just editorial and not any issue.

Mirja



> On 5. Mar 2020, at 14:17, Sara Dickinson <[e-mail]> wrote:
> 
> 
> 
>> On 4 Mar 2020, at 13:37, Mirja Kuehlewind <[e-mail]> wrote:
>> 
>> Hi Sara,
>> 
>> Thanks for you replies. See below.
>> 
>> 
>>> On 4. Mar 2020, at 14:30, Sara Dickinson <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>>> On 31 Jan 2020, at 10:45, Mirja Kühlewind via Datatracker <[e-mail]> 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……
>> 
>> Ah, okay! Actually maybe something that can be stated more explicitly in the intro to make sure people do miss that there are actually normative requirements. (Didn’t re-read the intro, so it might well be that it is clear already and I didn’t get it…)
> 
> Given this is the second or third time this has been raised I think that makes sense… How about adding this text immediately after the use of SHOULD in section 5”
> 
> “In other words these requirements are specified here as all being normative requirements, and are only classified by different levels of compliance in the rest of the document."
> 
>>> 
>>>> 
>>>> 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.
>> 
>> Ah, I didn’t match that on my read. Maybe just add a reference go Appendix B then?
> 
> In fact based on other comments the whole table is going to be moved to Appendix B and updated slightly which should make it much clearer I hope!
> 
>> 
>>> 
>>>> 
>>>> 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.
>> 
>> I there is no http, I don’t think this document should recommend use fo 443. See further below. 
>>> 
>>>> Why would you deploy DoT over 853?
>> 
>> Sorry I meant 443...
>> 
>> 
>>>> 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. 
>> 
>> I was guessing that, but I’m not connivence we should support that in an RFC (given we have DoH on 443 now as well).
> 
> There was actually quite some discussion on the DPRIVE list back in December about using port 443 because RFC7858 allowed it and there are use cases for it. The result was registering an ALPN for DoT:
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
> A separate IESG comment suggested adding the reference to that registration here which I agree with and that case it seems reasonable to leave this in the document?
> 
> Best regards
> 
> Sara. 
>