Subject: Re: [DNSOP] draft-sah-resolver-information (revised)

From: "John Dickinson" <[email-masked]>
Date: Mon, 03 Jun 2019 12:52:28 +0100

On 22 May 2019, at 23:30, Paul Hoffman wrote:

> Greetings again. Based on the input from the DNSOP and DOH lists, we revised draft-sah-resolver-information. We also created a new draft, draft-sah-resinfo-doh, to cover the main use case we have for getting information from a resolver, namely to get the DoH URI template and authentication information.
>
>> From the mailing list traffic, it seems like some of y'all only care about getting resolver information from DNS (hopefully DNSSEC-signed), while others are fine to use HTTPS with web PKI authentication, particularly when DNSSEC signing is not possible. We have left both methods in the main draft.
>
> We encourage more input.
>
> --Paul Hoffman
>
> ======
>        Title           : DNS Resolver Information Self-publication
>        Authors         : Puneet Sood
>                          Roy Arends
>                          Paul Hoffman
> 	Filename        : draft-sah-resolver-information-01.txt
> 	Pages           : 9
> 	Date            : 2019-05-22
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-sah-resolver-information/
>

Reference to SUDN in Introduction is no longer needed.

DNS-over-TLS and DNS-over-HTTPS are both abbreviated to DoT in the Security Considerations

Section 4 P3 s/returen/return/

Section 4 and 5.2 are a bit hard to follow (maybe I need more caffeine). I would suggest that you use the term key-value pair in place of name-value pair. Using the word name in DNS docs is bound to lead to confusion.

Also I was a bit confused by

4: “All names in the returned object MUST be defined in the IANA registry
   or begin with the substring "temp-“” and
   “As defined in Section 5.2, the
   IANA registry will not register names that begin with "temp-", so
   these names can be used freely by any implementer”

5.2: “Name: The name to be used in the JSON object.  This name MUST NOT
   begin with "temp-".

until I reread the words “or begin with the substring "temp-“” I think the could be clearer, something like:

All keys in the returned object MUST either be defined in the IANA registry or if for local use only they MAY begin with the substring "temp-“ since IANA registry will not register names that begin with "temp-“.

Finally, section 2

“Note that the answer given by the resolver cannot be validated with DNSSEC.”
Whilst I understand the reasons, is it reasonable that we are still trying to standardise responses that can not be signed? Is it not time to start mandating that DNSSEC is a MUST for all DNS responses and that includes ones sent over DoT and DoH (and any future DoFOO)? At the very least, there should be very detailed discussion in the security considerations section about the reasons for and impact of not using DNSSEC, which you have done, although I don’t like text that says “if it is using DoT it will know if the communication is authenticated (DoH is always authenticated)”

regards
John

John Dickinson

https://sinodun.com

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Jun 2019 16:04:45 +0000

Sorry for the delay, and thanks for the careful review.

> Reference to SUDN in Introduction is no longer needed.

Fixed.

> DNS-over-TLS and DNS-over-HTTPS are both abbreviated to DoT in the Security Considerations

Fixed.

> Section 4 P3 s/returen/return/

Fixed.

> Section 4 and 5.2 are a bit hard to follow (maybe I need more caffeine). I would suggest that you use the term key-value pair in place of name-value pair. Using the word name in DNS docs is bound t…

I am hesitant to make that change because "name" is the term used consistently in JSON (and thus also in I-JSON). JSON uses "name/value pair", so I'll change to that, but I recognized that this is not a substitute for caffeine. 

> All keys in the returned object MUST either be defined in the IANA registry or if for local use only they MAY begin with the substring "temp-“ since IANA registry will not register names that begin…

Good suggestion; fixed.

> Whilst I understand the reasons, is it reasonable that we are still trying to standardise responses that can not be signed?

That wording was left over from the -00 draft and is incorrect. Fixed.

--Paul Hoffman