Re-,
Please see inline.
Cheers,
Med
> -----Message d'origine-----
> De : last-call <last-call-bounces@xxxxxxxx> De la part de Martin
> Thomson
> Envoyé : mardi 28 juin 2022 02:06
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>;
> 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 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?
[Med] Yeah as per the text right after the one you commented:
In contexts where putting additional complexity on requesting hosts
is acceptable, returning an ADN only can be considered. The supplied
ADN will be processed by a host following the procedure in Section 5
of [I-D.ietf-add-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.
>
[Med] We always had 8.1 in mind when citing 8310 in that section, but..
> 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.
>
[Med] Here is a proposal for discussion:
NEW:
The client verifies the connection based on PKIX validation [RFC5280]
of the DNS resolver certificate and uses the validation techniques as
described in [RFC6125] to compare the authentication domain name
conveyed in the Encrypted DNS options to the certificate provided
(see Section 8.1 of [RFC8310] for more details). The client uses by
default PKIX validation unless configured otherwise.
> 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,
[Med] Malformed messages are handed as per base specs (these specs are already cited).
For the RA case, we leverage rfc8106#section-5.3.1 for the validation procedure. That section already says:
o If the DNS options are valid, the host SHOULD copy the values of
the options into the DNS Repository and the Resolver Repository in
order. Otherwise, the host MUST discard the options.
> 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?
[Med] Good question. An ALPN parameter must be present if both ADN/IP address are provided. Clarified this in the text.
>
> 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.
[Med] I think that these are no fixed on the PR. Thanks.
>
> 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
> >
> >
> __________________________________________________________________
> 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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
