Hi Med, Thanks for the changes, I have a few (blocking) comments on the pull request. 1. Thanks for the improvements, but I don't think that they go far enough to address the main concern. The specification needs to describe what happens when you only get an ADN. Do you do DDR? Do you have an A/AAAA fallback? These are non-trivial issues that the working group really needs to decide. 2. Wow. Given that your co-author is defending the right of implementations to choose different trust anchors, adding two characters to the spec (8 -> 8.1) without much comment might be a little much. Again, this is an important issue that the working group should discuss. I suggested to Tiru that maybe the right answer is to use Web PKI by default, with some allowance for other sources of trust anchor. That in itself is a controversial position too. I'm not up to date with the dprive discussion on using authenticated TLS toward authoritative servers, but at a minimum I would expect that state to be considered. 3. If there are specifications that already define error handling, please cite them. That's all I was looking for. I couldn't see anything in the specification as it relates to expectations about malformed options - if they are ignored when malformed, that's OK, but as it is highly relevant it is worth addressing. Also, what happens if you get ADN and IP, but no parameters (or the parameter length field)? Is that valid? 4. You appear to have moved things in the opposite direction to what I suggested. That is you now have more ascii art, and less semantic XML. On Mon, Jun 27, 2022, at 17:54, mohamed.boucadair@xxxxxxxxxx wrote: > Hi Martin, > > Thank you for the comments. > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : last-call <last-call-bounces@xxxxxxxx> De la part de Martin >> Thomson >> Envoyé : lundi 27 juin 2022 04:47 >> À : add@xxxxxxxx; last-call@xxxxxxxx >> Objet : Re: [Last-Call] [Add] Last Call: <draft-ietf-add-dnr- >> 09.txt> (DHCP and Router Advertisement Options for the Discovery >> of Network-designated Resolvers (DNR)) to Proposed Standard >> >> Hi, >> >> I found a few problems with this draft. >> >> 1. Provisioning >> >> In Section 3.1.6, there is this text: >> >> > ServiceMode (Section 2.4.3 of [I-D.ietf-dnsop-svcb-https]) >> SHOULD be used because the Encrypted DNS options are self- >> contained and do not require any additional DNS queries. >> >> When I first hit this text, I got the strong impression that >> DHCP/RA would be carrying SVCB resource records, but that is not >> the case. This text is therefore misleading. >> >> This leads to the next point, which is that there is a trap here >> for an incautious implementer that really needs to be better >> signposted. The name that is authenticated when you use AliasMode >> is the **input** name. If you supply an authenticated domain name >> and populate DHCP using the ServiceMode results, they risk >> skipping over any names that might have been queried in that >> process, either those with AliasMode SVCB records or those with >> CNAME records. >> >> This text needs to be clarified and the pitfalls better >> signposted. > > [Med] A wording proposal can be seen at: > https://github.com/boucadair/draft-btw-add-home-network/pull/10/. Hope > this is better. > > Please note that we don't return an alias in the ADN-only mode but the > target name. That name will be processed following Section 5 of DDR. > >> >> 2. Authentication >> >> In Section 3.3 there is this text: >> >> > The client follows the mechanism discussed in Section 8 of >> [RFC8310] to authenticate the DNS resolver certificate using the >> authentication domain name conveyed in the Encrypted DNS options. >> >> This is not a specification that can be implemented interoperably. >> Despite it being on the standards track[1], RFC 8310 is a >> multiple-choice questionnaire, not an interoperable protocol >> specification. It offers a number of deployment options. It is >> not sufficient to leave clients to guess which or for servers to >> support all options to allow clients a choice. Even if this >> document doesn't choose, the implications of not choosing need to >> be properly documented (which is probably more work than choosing, >> frankly). >> > > [Med] Updated the reference to point specifically to 8.1 of 8310. Do > you see any "deployment options" in that section? > >> 3. Error Handling >> >> The specification does not describe how to handle poorly formatted >> options. > > [Med] We don't because that would be redundant with what is already > defined in the base specs (8415, 2131, ..). For RA, we leverage the > behavior specified in Section 5.3.1 of [RFC8106]. > >> >> 4. Other >> >> There are a number of formatting issues (Section 8.2 has a diagram >> containing a table rather than a table); same for the aside in >> Section 3.1.1 and Section 10. There were a number of other issues >> that would have resulted in a pull request, had a destination for >> that existed. > > [Med] Thanks for catching those. Tried to fix some of them in the PR. > >> >> [1] A mistake, in my opinion. >> >> On Sat, Jun 25, 2022, at 03:30, The IESG wrote: >> > The IESG has received a request from the Adaptive DNS Discovery >> WG >> > (add) to consider the following document: - 'DHCP and Router >> > Advertisement Options for the Discovery of Network- >> > designated Resolvers (DNR)' >> > <draft-ietf-add-dnr-09.txt> as Proposed Standard >> > >> > The IESG plans to make a decision in the next few weeks, and >> solicits >> > final comments on this action. Please send substantive comments >> to the >> > last-call@xxxxxxxx mailing lists by 2022-07-08. Exceptionally, >> > comments may be sent to iesg@xxxxxxxx instead. In either case, >> please >> > retain the beginning of the Subject line to allow automated >> sorting. >> > >> > Abstract >> > >> > >> > The document specifies new DHCP and IPv6 Router Advertisement >> options >> > to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, >> DNS-over- >> > TLS, DNS-over-QUIC). Particularly, it allows a host to learn >> an >> > authentication domain name together with a list of IP >> addresses and a >> > set of service parameters to reach such encrypted DNS >> resolvers. >> > >> > >> > >> > >> > The file can be obtained via >> > https://datatracker.ietf.org/doc/draft-ietf-add-dnr/ >> > >> > The ADD WG has another document >> > https://datatracker.ietf.org/doc/draft-ietf-add-ddr/, which >> should >> > probably be reviewed at the same time. >> > >> > No IPR declarations have been submitted directly on this I-D. >> > >> > >> > >> > >> > >> > -- >> > Add mailing list >> > Add@xxxxxxxx >> > https://www.ietf.org/mailman/listinfo/add >> >> -- >> last-call mailing list >> last-call@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/last-call > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme > ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > -- > Add mailing list > Add@xxxxxxxx > https://www.ietf.org/mailman/listinfo/add -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
