Re: [Add] I-D Action: draft-ietf-add-dnr-01.txt

[Ben Schwartz <[e-mail]>]

Thanks for this update.  I think this is a good design.

Some notes:

Sections 4-6:
The ADN is self-delimiting, so the ADN length field is redundant in both
encodings.  (It's also unnecessarily wide in the IPv6 encodings, since
domain names are limited to 255 octets.)  I would suggest getting rid of
the ADN length field.  For precedent, see the DNSSL option (RFC 8106
Section 5.2).

I wonder if anyone else would prefer an Addr Count instead of Addr Length?
That would allow us to have a consistent 1-byte field for v4 and v6, and
avoid the divisibility requirements.  Better to multiply than divide!

I think the draft should probably have a one-sentence warning like "Senders
SHOULD NOT include ipv4hint or ipv6hint SvcParams, which would be
superseded by the included addresses."

Section 7 and Appendices A+B:

I think these sections should move to a separate draft (where they can be
full-fledged body text, and not merely appendices).  This guidance is not
specific to DNR (it also applies to DDR), and applies to very particular
deployment scenarios.  I also think that this operational guidance is much
more speculative than the format itself, and I'd like them to be able to
make progress independently.

Section 8:

I would like this section to take a different approach.  Rather than simply
enumerating attacks, I think we should be discussing the security
properties that this process provides.  In particular, we need to be clear
that DNR can guarantee that the resolver is the one selected by the DHCP
sender, but it cannot provide any information about who that sender is.

One particular note: The draft says "Also, an attacker can use a public IP
address and get an 'IP address'-validated public certificate from a CA to
host an Encrypted DNS server.".  This is currently not supported: DNR
requires an Authentication Domain Name, which cannot be an IP address.
(That's OK with me; I just think the text should be consistent.)

On Tue, May 4, 2021 at 6:03 AM <[e-mail]> wrote:

> Hi all,
>
> This version takes into account the inputs received during the last IETF
> meeting: that is, leverage SVCB. One single option is thus defined to carry
> the authentication domain name, IP address(es), and service parameters. The
> service parameters are encoded as SvcParams specified in the SVCB I-D. We
> added text to explain the rationale of reusing that encoding + why one
> single option is defined.
>
> We also updated the structure of section 3 to take into account some of
> the comments from Michael.
>
> The DHCP part was reviewed by Bernie (co-chair of dhc wg). All seems good.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Add [mailto:[e-mail]] De la part de internet-
> > [e-mail]
> > Envoyé : mardi 4 mai 2021 14:42
> > À : [e-mail]
> > Cc : [e-mail]
> > Objet : [Add] I-D Action: draft-ietf-add-dnr-01.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Adaptive DNS Discovery WG of the
> > IETF.
> >
> >         Title           : DHCP and Router Advertisement Options for
> > the Discovery of Network-designated Resolvers (DNR)
> >         Authors         : Mohamed Boucadair
> >                           Tirumaleswar Reddy
> >                           Dan Wing
> >                           Neil Cook
> >                           Tommy Jensen
> >       Filename        : draft-ietf-add-dnr-01.txt
> >       Pages           : 30
> >       Date            : 2021-05-04
> >
> > Abstract:
> >    The document specifies new DHCP and IPv6 Router Advertisement
> > options
> >    to discover encrypted DNS servers (e.g., DNS-over-HTTPS, DNS-over-
> >    TLS, DNS-over-QUIC).  Particularly, it allows to learn an
> >    authentication domain name together with a list of IP addresses
> > and a
> >    set of service parameters to reach such encrypted DNS servers.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-add-dnr/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-add-dnr-01
> > https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr-01
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-add-dnr-01
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> > tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > --
> > Add mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/add
>
>
> _________________________________________________________________________________________________________________________
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>