Subject: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-server-discovery-13: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 26 Oct 2020 19:06:38 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dots-server-discovery-13: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Pulling in some follow-up from the directorate review comments...

Section 3

   o  Resolving a DOTS server domain name offered by an upstream transit
      provider provisioned to a DOTS client into IP address(es) requires
      the use of the appropriate DNS resolvers; otherwise, resolving
      those names will fail.  The use of protocols such as DHCP does
      allow associating provisioned DOTS server domain names with a list
      of DNS servers to be used for name resolution.  Furthermore, DHCP
      allows directly provisioning IP addresses therefore avoiding the
      need for extra lookup delays.

I wonder if using "providing" rather than "provisioning" for at least the
last instance would be more clear.

   o  A resolution mechanism based on straightforward Naming Authority
      Pointer (S-NAPTR) resource records in the Domain Name System (DNS)
      (Section 6).

"Straightforward" needs to be capitalized here.

Section 4

   will support a local configuration.  More samples are discussed in
   Section 3:

nit: s/:/./

Section 5

   The list of the IP addresses returned by DHCP servers is typically
   used to feed the DOTS server selection procedure including when DOTS
   agents are provided with primary and backup IP addresses of their
   peer DOTS agents.  An example of DOTS server selection procedure is
   specified in Section 4.3 of [RFC8782].

The referenced section in 8782 is about the "happy eyeballs", i.e.,
picking between TCP/UDP and IPv4/IPv6 -- it doesn't really seem intended
to cover the case where you have to pick betwen different actual nodes.

I'm also not sure how the "primary and backup" is intended to work,
here.  Is the "provided with" referring to "by DHCP" or some out-of-band
configuration?

Section 8.1

   configured name.  If the DOTS agent is instructed to trust subdomains
   of the names in that list as well, a DOTS agent will also accept a
   DHCP-discovered name if the left-most label of the discovered name is
   matching a name in the pre-configured list.

If the agent is configured to trust subdomains of the configured list,
then in the case where that configuration is relevant for the attack,
the left-most label will be the (part of the) subdomain name, which is
explicitly not matching the pre-configured list -- the remaining bits
are what match.

---

From: <[email-masked]>
Date: Tue, 27 Oct 2020 07:25:06 +0000

Hi Ben, 

An updated version is available at: https://tinyurl.com/dots-discovery-iesg 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk via Datatracker [mailto:[email-masked]]
> Envoyé : mardi 27 octobre 2020 03:07
> À : The IESG <[email-masked]>
> Cc : [email-masked]; dots-
> [email-masked]; [email-masked]; Valery Smyslov <[email-masked]>;
> [email-masked]
> Objet : Benjamin Kaduk's Yes on draft-ietf-dots-server-discovery-13:
> (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> I wonder if using "providing" rather than "provisioning" for at
> least the last instance would be more clear.

[Med] Works for me. 

> "Straightforward" needs to be capitalized here.

[Med] Fixed. Thanks. 

>    will support a local configuration.  More samples are discussed

[Med] OK.

> picking between TCP/UDP and IPv4/IPv6 -- it doesn't really seem
> intended to cover the case where you have to pick betwen different
> actual nodes.

[Med] That text is about an example of address selection procedure (including between nodes: think about a dual stack host that receives both v4 and v6 config). It is useful as it refers (indirectly) to RFC6724 which allows for configuring a preference ... 

> here.  Is the "provided with" referring to "by DHCP" or some out-of-
> band configuration?

[Med] ... I thought we had this already covered in the text, but it isn't. I added "The addresses are listed in the order of preference for use by the DOTS agent." so that a preference is signalled by the server to the a requesting DHCP client.

The primary will be listed first. 

> If the agent is configured to trust subdomains of the configured
> list, then in the case where that configuration is relevant for the
> attack, the left-most label will be the (part of the) subdomain
> name, which is explicitly not matching the pre-configured list --
> the remaining bits are what match.
> 
[Med] Changed the wording as follows:

"If the DOTS agent is instructed to trust subdomains of the names in that list as well (e.g., "*.example.com"), a DOTS agent will accept a DHCP-discovered name that matches a name in the pre-configured list (e.g., "dots-1.example.com" or "dots-2.example.com")."

_________________________________________________________________________________________________________________________

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: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Oct 2020 09:14:32 -0700

Thanks, Med.

Please go ahead and upload a -14 if you get the chance; most of the IESG
will not start reviewing (for next week's telechat) until the end of this
week.

-Ben