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

From: [email-masked]
Date: Tue, 04 May 2021 05:42:08 -0700

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/

---

From: <[email-masked]>
Date: Tue, 4 May 2021 13:03:23 +0000

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:[email-masked]] De la part de internet-
> [email-masked]
> Envoyé : mardi 4 mai 2021 14:42
> À : [email-masked]
> Cc : [email-masked]
> Objet : [Add] I-D Action: draft-ietf-add-dnr-01.txt
> 
> 
>         Title           : DHCP and Router Advertisement Options for
> the Discovery of Network-designated Resolvers (DNR)
> 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.
> 
> --
> Add mailing list
> [email-masked]
> 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.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 4 May 2021 16:11:11 -0700

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 <[email-masked]> 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.
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Wed, 5 May 2021 05:50:50 +0000

Hi Ben,

Thank you for the comments.

Please see inline.

Cheers,
Med

De : Ben Schwartz [mailto:[email-masked]]
Envoyé : mercredi 5 mai 2021 01:11
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : [email-masked]
Objet : Re: [Add] I-D Action: draft-ietf-add-dnr-01.txt

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!
[Med] I confirm that we first considered “Addr Count” but changed it. This was one of the discussion points I had with Bernie and which triggered this thread in dhc WG: https://mailarchive.ietf.org/arch/msg/dhcwg/baHgUt99kHmqSB5pmhPm6YyN4O4/. For the your two points above, we will be following the guidelines from the dhc wg.

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."
[Med] I went for a more strict wording:

“The service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the included IP addresses.”

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.
[Med] I’m not sure if all applies to DDR, but it is fair to ask for separating the options design vs. deployment considerations. Let’s see what others think about this.

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.
[Med] This is more valid on the LAN side, not the WAN side.

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.)
[Med] This one is left on purpose as the current spec does not preclude returning an “ADN Length” set to 0. In such case the IP address will be used as the authentication reference identifier. We don’t have an explicit text for it but this is a point we would like to have more feedback from the WG.

On Tue, May 4, 2021 at 6:03 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Cheers,
Med

> De : Add [mailto:[email-masked]<mailto:[email-masked]>] De la part de internet-
> [email-masked]<mailto:[email-masked]>
> À : [email-masked]<mailto:[email-masked]>
> Cc : [email-masked]<mailto:[email-masked]>
> tools.ietf.org<http://tools.ietf.org>.
>
> [email-masked]<mailto:[email-masked]>

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add

---

From: <[email-masked]>
Date: Tue, 18 May 2021 06:30:13 +0000

Hi Ben, all,

As we didn’t hear any objection to the proposals discussed in this thread, we updated the draft as follows:

·         Move deployment-related sections to a separate draft

·         Add a statement to avoid including “ipv4hint" and "ipv6hint in the service parameters

·         Add a NEW text about security properties provided by DNR

The latest version can be seen at:

https://datatracker.ietf.org/doc/html/draft-ietf-add-dnr-02

https://www.ietf.org/rfcdiff?url2=draft-ietf-add-dnr-02

Cheers,
Med

De : Add [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 5 mai 2021 07:51
À : Ben Schwartz <[email-masked]>
Cc : [email-masked]
Objet : Re: [Add] I-D Action: draft-ietf-add-dnr-01.txt

Hi Ben,

Please see inline.

Cheers,
Med

À : BOUCADAIR Mohamed TGI/OLN <[email-masked]<mailto:[email-masked]>>

Some notes:

Sections 4-6:

Section 8:

Cheers,
Med