Discovery of Designated Resolvers
draft-ietf-add-ddr-10
Yes
Éric Vyncke
No Objection
(Alvaro Retana)
(Martin Duke)
Abstain
Note: This ballot was opened for revision 07 and is now closed.
Erik Kline
Yes
Comment
(2022-07-12 for -08)
Sent
# Internet AD comments for {draft-ietf-add-ddr-08} CC @ekline ## Comments ### S2 * I might suggest a slightly less binding wording where port 53 is concerned for the Unencrypted Resolver definition. Perhaps: "A DNS resolver using a transport without encryption, historically TCP or UDP port 53." ### S4 * I'd be in favor of using more RFC 8174 "SHOULD/SHOULD NOT" text in place of "ought [not] to". Specifically, for the text about address family support, consider perhaps something like: OLD: ... The Designated Resolver can support more address families than the Unencrypted Resolver, but it ought not to support fewer. NEW: ... The Designated Resolver MAY support more address families than the Unencrypted Resolver, but it SHOULD NOT support fewer. ### S5, S6.3, ... * I wonder if it's good to require that clients MUST NOT/SHOULD NOT accept certificates claiming to be for resolver.arpa? This might be over-specifying things and/or it might be a check against some types of misconfigurations.
Éric Vyncke
Yes
Francesca Palombini
No Objection
Comment
(2022-07-14 for -08)
Not sent
Thank you for the work on this document. Many thanks to Thomas Fossati for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/PT-6Rhoa4WieVi3lmSFMhlvbSo4/, and to the authors for addressing Thomas' comments. Francesca
John Scudder
No Objection
Comment
(2022-07-12 for -08)
Sent
Thanks for the painless read! Just a few trivial comments. Minor: 1. The editorial commentary in the IANA Considerations section seems out of place -- generally IANA Considerations is, well, requests to IANA, not interesting and fun trivia about the resources being requested. But, IANA are smart enough to disregard the superflous material. Nits: 2. §3, The client can still use others records in the same response s/others/other/ 3. §7, provides provides s/provides//
Murray Kucherawy
No Objection
Comment
(2022-07-14 for -08)
Sent
I support Lars's DISCUSS blocking for IANA actions. Specifically, the problem seems to be that RFC 6761 wasn't followed. Please review that document, and in particular its Section 5. Thanks to Thomas Fossati for his ARTART review. I think there are way too many bald SHOULDs in this document. Since SHOULD presents an implementer with a choice, it's usually a good idea to describe that choice rather than presenting something that looks like "you really should do this, but it's probably fine if you don't" and moves on. To wit: * An example of one that could use improvement is the first one in Section 4, as I've no idea why you would not always do what it says. * An example of one that does provide such guidance is the second one in Section 4, where I understand the consequences of not doing what it says.
Roman Danyliw
No Objection
Comment
(2022-07-12 for -08)
Sent
** Thank you to Ben Schwartz for the IETF LC SECDIR review. This review highlights several places where design choices or implementation guidance would benefit from additional explanatory text. Instead of repeating the issues here, please see https://mailarchive.ietf.org/arch/msg/secdir/WWrVmObWkKeBNDI-fPhV7Jipn3c/. ** Section 4.2 2. The client MUST verify that the certificate contains the IP address of the designating Unencrypted Resolver in a subjectAltName extension. Consider being more precise by saying: NEW 2. The client MUST verify that the certificate contains the IP address of the designating Unencrypted Resolver in an iPAddress entry of the subjectAltName extension (see 4.2.1.6 of [RFC5280]). ** Section 5. For these cases, the client simply sends a DNS SVCB query using the known name of the resolver. This query can be issued to the named Encrypted Resolver itself or to any other resolver. Unlike the case of bootstrapping from an Unencrypted Resolver (Section 4), these records SHOULD be available in the public DNS. If there was a limited domain mechanism using DDR, why would these records be in public DNS?
Warren Kumari
(was Discuss)
No Objection
Comment
(2022-07-13 for -08)
Sent
[ Thank you for addressing my DISCUSS (see https://mailarchive.ietf.org/arch/msg/add/KhCzRdbyoq8fo-LlEr5FOW61PGA/ ) - I'm clearing and trusting that y'all will fold in the PR and answer the questions. ] Has the potential new load that this introduces on the .arpa servers been considered and discussed with the IANA? Yes, the document says that the name should also be added to the "Locally-Served DNS Zones" registry, but obviously that doesn't get deployed immediately (13 years after j.root-servers.net changed addresses, it was (and still is!) getting queries on the old address: https://indico.dns-oarc.net/event/24/contributions/378/attachments/353/613/2015-old-j-root.pdf ) Probably the ARPA servers don't care, but it seems impolite to not at least ask...
Zaheduzzaman Sarker
No Objection
Comment
(2022-07-14 for -08)
Sent
Thanks for working on this specification. I have one comment - - section 4.2: needs a reference/description for "subjectAltName extension"
Paul Wouters
(was Discuss)
Abstain
Comment
(2022-08-08)
Sent
# SEC AD comments for {draft-ietf-add-ddr-10} CC @paulwouters ## Abstain I find the set of documents in the ADD WG incomplete from a security point of view. This is due to client policy being purposefully left out of the WG charter, which is unfixable at this point in the process. I will therefore abstain so that these documents can be published. Hopefully, a BoF/WG in the future will attempt to address this security problem. ## unresolved DISCUSS items Below follows my specific old DISCUSS items that were not addressed. ### Clients MUST NOT automatically use a Designated Resolver without some sort of validation Why not? What is the alternative? Using unencrypted DNS to the party that told you how and where to contact these (unvalidated) Designated Resolvers. ### 2. The client MUST verify that the certificate contains the IP address of the designating Unencrypted Resolver in a subjectAltName extension. How feasible is it to get a certificate with SAN=ip from one of the generally accepted root store CA's? Can you give me one example where I can get a certificate for nssec.nohats.ca with SAN=193.110.157.123 ? I do not think this is currently possible or easy. If I am right, that means all of Section 4.2 is wishful thinking and not realistic to get rolled out. (I know we can see the cert for 1.1.1.1, so it is possible, but I know of no ACME supported CA that issues these) ### If these checks fail, the client MUST NOT automatically use the discovered Designated Resolver. This creates a strange policy when compared to DNR where if you get a DHCP or RA for the Designated Resolver, which is also not validatable, that you do end up using it? And section 6.5 states DNR trumps DDR. Note: this was updated in -10 to match the DNR, but it matches the weak method of DHCP/RA, so that if the TLS checks fail, it might still end up being used as "Verified Discovery". ### If the Designated Resolver and the Unencrypted Resolver share an IP address, clients MAY choose to opportunistically use the Designated Resolver even without this certificate check (Section 4.3). Why only when the IP is the same? Why not for when the IP is different? What's to lose, since the only fallback option is stick to using the unencrypted resolver? ### Opportunistic Discovery has the same "same IP" issue. As the alternative is to use unencrypted DNS, why not just use it anyway? Note: the text was changed but the issue remains ### A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" upstream. Unfortunately, all currently deployed software does not know this, so it will be very common that this happens. Note: Also, why is this not a MUST NOT? ### To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. I don't see how this would improve security for the client. It also mixes up behaviour of proper DNS clients that have their own retransmit logic for if they get no answer. ### Section 8.2 of [I-D.ietf-add-svcb-dns] describes a second downgrade attack where an attacker can block connections to the encrypted DNS server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed. For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires I wonder which attacker can block encrypted DNS connections but not spoof (or block!) an unsigned SVCB record to the local client? And even if that is the case, this would be a denial of service attack if the DNS client cannot fallback to unencrypted DNS. Spoofing an SVCB to a bogus IP with an SVCB TTL of a few hours would be a very cheap 1 packet attack to keep the DNS client down for hours. This seems dangerous to implement. ### DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the HTTP path alone, since an attacker could modify the "dohpath" parameter. For example, if a DoH resolver provides provides a filtering service for one URI path, and a non-filtered service for another URI path, [...] It seems likely that this advise will get ignored a lot, eg by people who have limited public IPs to use to spin up a DoH server, or who have to pay-per-IP. This advise seems more appropriate for local private IP DoH servers. So I would change this MUST NOT to SHOULD NOT for that reason. ## If the IP address of a Designated Resolver differs from that of an Unencrypted Resolver, clients applying Verified Discovery (Section 4.2) MUST validate that the IP address of the Unencrypted Resolver is covered by the SubjectAlternativeName of the Designated Resolver's TLS certificate. How would one obtain such a certificate via ACME? Since on the IP of the unencrypted resolver, there would be no HTTP server running? Additionally, if the client notices a failed verification of the Designated Resolver's TLS certificate, wouldn't it fallback to the Unencrypted Resolver? But now it may not? So this becomes a denial of service then ? ### I kind of miss the mode of where there is no indication of DDR or DNR, and you use "unilateral probing" (draft-ietf-dprive-unilateral-probing) to just connect to the DoT or DoQ ports of the Unencrypted Resolver and see if you get anything back. It might be unauthenticated TLS but better than port 53? ## Unresolved Comments ### section 3 To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of [RFC8484] regarding the avoidance of DNS- based references that block the completion of the TLS handshake. I find that reference to list more the issues than solutions that can be followed. The solution to use another DoH server is not really appropriate in most cases The client's other interface likely resides on other networks where its private DoH server cannot resolve the name of another network's private DoH server. It is also not easy to get an IP based certificate (eg SAN=ip) that is accepted by general webpki root stores. And things like OCSP stapling doesn't help if the target is malicious - they just would omit the stapling that proves against its malicious use. The only real advise usable from RFC8484 is "use the local unencrypted resolver to resolve the encrypted resolver". Might as well say that and remove the 8484 reference.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -08)
Not sent
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2022-07-26 for -08)
Sent for earlier
# GEN AD review of draft-ietf-add-ddr-08 CC @larseggert Thanks to Robert Sparks for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/mHeRXL46i0vY3KUKqmxW7l4ZP_k). ## Comments ### Section 2, paragraph 5 ``` Encrypted Resolver: A DNS resolver using any encrypted DNS transport. This includes current mechanisms such as DoH, DoT, and DoQ, as well as future mechanisms. Unencrypted Resolver: A DNS resolver using TCP or UDP port 53 without encryption. ``` Wouldn't "unencrypting resolver" be a more accurate term? (Same for "encrypting resolver".) ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `blind`; alternatives might be `visually impaired`, `unmindful of`, `unconcerned about`, `negligent of`, `unaware`, `uncomprehending`, `unaware`, `uncritical`, `unthinking`, `hasty`, `blocked`, `opaque` ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Grammar/style #### Section 4, paragraph 5 ``` an IPv6 address, it ought to provide a AAAA record for an IPv6 address of th ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". #### Section 6.5, paragraph 1 ``` r example, if a DoH resolver provides provides a filtering service for one U ^^^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
Martin Duke Former IESG member
No Objection
No Objection
(for -08)
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
(2022-07-13 for -08)
Sent
Hi, Thanks for this. Re: section1, Introduction: Such mechanisms include network provisioning protocols like DHCP [RFC2132] [RFC8415] and IPv6 Router Advertisement (RA) options [RFC8106], as well as manual configuration. Do you know if there is any work being done in the IETF to add more options to DHCP, RA, or manual configuration to allow more complex DHCP server information to be provisioned/setup? Since longer term that would seem to be an easier/safer solution than needing to use SVCB records to move from unencrypted to encrypted comms. 2) I also had a question regarding section 5: In the following example, the SVCB answers indicate that resolver.example.com supports both DoH and DoT, and that the DoH server indicates a higher priority than the DoT server. _dns.resolver.example.com. 7200 IN SVCB 1 resolver.example.com. ( alpn=h2 dohpath=/dns-query{?dns} ) _dns.resolver.example.com. 7200 IN SVCB 1 resolver.example.com. ( alpn=dot ) Is there a bug in the example (e.g., second entry should be 2 rather than 1)? Or otherwise it wasn't obvious to me why DoH had higher priority. Regards, Rob