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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
