Subject: [Dots] Éric Vyncke's Discuss on draft-ietf-dots-server-discovery-14: (with DISCUSS and COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 03 Nov 2020 10:56:59 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-dots-server-discovery-14: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document. It is easy to read.

Please find below a couple of blocking DISCUSS points and some non-blocking
COMMENT points and some nits.

In addition to my own points, please consider Zhen Caos' INT directorate review
at:
https://datatracker.ietf.org/doc/review-ietf-dots-server-discovery-11-intdir-lc-cao-2020-10-12/

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 4 --
Trivial to fix: there is no "DHCP lease" for stateless DHCPv6... You should
probably rather refer to the information-request refresh time option (section
21.23 of RFC 8415).

-- Section 5.1.2 --
I fully second Zhen Cao's review: how will the IPv4-mapped IPv6 address(es) be
used? They MUST not appear on the wire and there is a DHCPv4 option to convey
the DOTS information. Is it when DHCPv6 is available, no DHCPv4, and only IPv4
connectivity to the DOTS server ? If so, then please clarify the text.

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

Is DHCP really the way to go ? Even if it seems that there are use cases,
relying on dynamic DHCP for such an important security protocol looks very
strange to me (as the security AD has approved DHCP use, it is a mere
non-blocking comment).

Should DNSSEC be required for domain name resolution or is relying only on TLS
server authentication enough ?

The document gives a lot of IPv6 examples: thank you for this but it also
mention multiple address families. Should Happy Eyeball be used when connected
to the DOTS server?

-- Section 4 --
While this section title is "Unified DOTS Discovery Procedure", I read 3
different mechanisms so apparently conflicting with the section title. Suggest
to remove "unified" from the section title.

Putting DHCP configuration under explicit configuration appears weird to me as
DHCP is rather dynamic and on the same level as DNSD.

May I suggest to move the sentence "DOTS clients will prefer information
received from the discovery methods in the order listed" before the list? It is
an important sentence IMHO.

I wonder wheter the sentence "Expiry of a peer DOTS agent's certificate
currently in use." is correct... Should it be "agent peer DOTS certificate" ?

-- Sections 5.1.3 and 5.2.3--
The part of the sentence "as distinguished by the presence of multiple root
labels" should be explained more as it is unclear.

-- Section 6 --
Just to say that the use of S-NAPTR surprised me (no need to reply)

== NITS ==

The id-nits tool indicates a non used reference to RFC 8783, so, please clean
up the reference list ;-)

-- Section 1 --
s/by multi-homed DOTS clients are out of scope/by multi-homed DOTS clients are
out of this document scope/ ?

---

From: <[email-masked]>
Date: Wed, 4 Nov 2020 07:15:11 +0000

Bonjour Eric, 

Thank you for the review. 

I updated the document to take into account your review (at least, parts I agree with :-)): https://tinyurl.com/dots-discovery-iesg 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker [mailto:[email-masked]]
> Envoyé : mardi 3 novembre 2020 19:57
> À : The IESG <[email-masked]>
> Cc : [email-masked]; dots-
> [email-masked]; [email-masked]; Valery Smyslov <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Objet : Éric Vyncke's Discuss on draft-ietf-dots-server-discovery-
> 14: (with DISCUSS and 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.)
> 
> 
> Please find below a couple of blocking DISCUSS points and some non-
> blocking COMMENT points and some nits.
> 

[Med] Already considered. Unless I'm mistaken there is no follow-up to https://mailarchive.ietf.org/arch/msg/int-dir/Yh_Vk4RLltG9PGg2W6ZSe1CHy0Y/. 

> Trivial to fix: there is no "DHCP lease" for stateless DHCPv6... You
> should probably rather refer to the information-request refresh time
> option (section
> 21.23 of RFC 8415).

[Med] Added "DHCP information refresh time," to the list of examples.

> 
> -- Section 5.1.2 --
> I fully second Zhen Cao's review: how will the IPv4-mapped IPv6
> address(es) be used? They MUST not appear on the wire and there is a
> DHCPv4 option to convey the DOTS information. Is it when DHCPv6 is
> available, no DHCPv4, and only IPv4 connectivity to the DOTS server
> ? If so, then please clarify the text.
> 

[Med] You got it. Added: " This is particularly useful in IPv4 service continuity deployments where only DHCPv6 is used."

> Is DHCP really the way to go ? Even if it seems that there are use
> cases, relying on dynamic DHCP for such an important security
> protocol looks very strange to me

[Med] We do rely on DHCP to provide the reachability information of other sensitive services. Please note that credentials are no communicated using DHCP. Do you see anything to add to?

   An attacker can get a domain name, domain-validated public
   certificate from a CA, and host a DOTS agent.  An active attacker can
   then spoof DHCP responses to include the attacker's DOTS agent.  Such
   an attacker can also launch other attacks as discussed in Section 22
   of [RFC8415].  In addition to the mitigations listed in Section 22 of
   [RFC8415], a DOTS agent may be pre-configured with a list of trusted
   DOTS domain names.  If such a list is pre-configured, a DOTS agent
   will accept a DHCP-discovered name if it matches a name in that list.
   Also, the DOTS agent has to check that the 'DNS-ID' identifier type
   within subjectAltName in the server certificate matches a pre-
   configured name.  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").

 (as the security AD has approved
> DHCP use, it is a mere non-blocking comment).
> 
> Should DNSSEC be required for domain name resolution

[Med] This is discussed in both 8.2 and 8.3. Please let us know if any change is needed. 

 or is relying
> only on TLS server authentication enough ?
> 
> The document gives a lot of IPv6 examples: thank you for this but it
> also mention multiple address families. Should Happy Eyeball be used
> when connected to the DOTS server?

[Med] The answer is Yes. A pointer to the DOTS Happy Eyeball is provided in the text: Section 4.3 of RFC8782. 

> 
> -- Section 4 --
> While this section title is "Unified DOTS Discovery Procedure", I
> read 3 different mechanisms so apparently conflicting with the
> section title. Suggest to remove "unified" from the section title.

[Med] It is "unified" in the sense that the different mechanisms as packaged to form one with an internal preference order. OK to remove it if it hurts.   

> 
> Putting DHCP configuration under explicit configuration appears
> weird to me as DHCP is rather dynamic and on the same level as DNSD.

[Med] Not sure what is weird there. There two levels of explicit config as detailed in the text. 

> 
> May I suggest to move the sentence "DOTS clients will prefer
> information received from the discovery methods in the order listed"
> before the list? It is an important sentence IMHO.

[Med] It is important in case the client supports many mechanisms and receives the information using various sources.

> 
> I wonder wheter the sentence "Expiry of a peer DOTS agent's
> certificate currently in use." is correct... Should it be "agent
> peer DOTS certificate" ?

[Med] Would the "Expiry of the certificate of a peer DOTS agent" be better? To be honest, I'm not sure to get the issue with the initial wording. 

> The part of the sentence "as distinguished by the presence of
> multiple root labels" should be explained more as it is unclear.

[Med] If multiple names were included, then each of these names will be terminating with a byte value of 0. We drafted the text with the assumption that the reader is familiar with Section 3.1 of RFC1035.

Feel free to propose any better wording. Thanks.

> The id-nits tool indicates a non used reference to RFC 8783, so,
> please clean up the reference list ;-)

[Med] Thanks for catching this. It should be cited:

OLD: the DOTS data channel protocol [RFC8782]
NEW: the DOTS data channel protocol [RFC8783]

> 
> -- Section 1 --
> s/by multi-homed DOTS clients are out of scope/by multi-homed DOTS
> clients are out of this document scope/ ?
> 

[Med] Fixed. Thanks. 

_________________________________________________________________________________________________________________________

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: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 4 Nov 2020 10:49:18 +0000

Re-bonjour Med,

I have removed the parts where we agree. Additional comments are prefixed by EV>

Regards

-éric

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Wednesday, 4 November 2020 at 08:15
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Valery Smyslov <[email-masked]>, "[email-masked]" <[email-masked]>, "Bernie Volz (volz)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Éric Vyncke's Discuss on draft-ietf-dots-server-discovery-14: (with DISCUSS and COMMENT)

EV> I am afraid that more text and explanations are required to clear my remaining DISCUSS even if your suggested modification is a big step forward

EV> yes, please remove the "unified" in the section title

EV> but my point is that DHCP is not really an explicit configuration rather a dynamic one. So, I do not see why the DHCP part is on the same level as static configuration in the 1st item in the list

EV> sure but my point was to move this sentence *before* the enumeration due to its importance.

EV> it is indeed easier to read  / parse for a non-English reader like myself

EV> sure about RFC 1035 ;-) but I wonder whether this part of the sentence is useful as the previous part " OPTION_V6_DOTS_RI contains more than one name" seems perfectly enough for me so reader may wonder about the part " as distinguished by the presence of multiple root labels"

---

From: <[email-masked]>
Date: Wed, 4 Nov 2020 11:48:02 +0000

Re-,

Thanks, Eric. 

Please see inline.

Cheers,
Med

> De : Eric Vyncke (evyncke) [mailto:[email-masked]]
> Envoyé : mercredi 4 novembre 2020 11:49
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>; The
> IESG <[email-masked]>
> [email-masked]; Bernie Volz (volz) <[email-masked]>;
> [email-masked]
> Objet : Re: Éric Vyncke's Discuss on draft-ietf-dots-server-
> discovery-14: (with DISCUSS and COMMENT)
> 
> Re-bonjour Med,
> 
> Cc: "[email-masked]" <draft-ietf-dots-
> [email-masked]>, "[email-masked]" <dots-
> [email-masked]>, "[email-masked]" <[email-masked]>, Valery Smyslov
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, "Bernie Volz (volz)" <[email-masked]>,
> "[email-masked]" <[email-masked]>
>     [Med] You got it. Added: " This is particularly useful in IPv4
> service continuity deployments where only DHCPv6 is used."
> 
> EV> I am afraid that more text and explanations are required to
> clear my remaining DISCUSS even if your suggested modification is a
> big step forward
> 

[Med] We can add some pointers rather than expanding the text. What about:  

"This is particularly useful in IPv4 service continuity deployments (e.g., [RFC6333]) where only DHCPv6 is used and DHCPv4-over-DHCPv6 [RFC7341] is not supported." 

>     [Med] It is "unified" in the sense that the different mechanisms
> as packaged to form one with an internal preference order. OK to
> remove it if it hurts.
> 

[Med] Done. 

> EV> but my point is that DHCP is not really an explicit
> configuration rather a dynamic one.

[Med] I don’t get this one. An explicit config can be provided using static or dynamic mechanisms. DHCP falls into the second category. 

 So, I do not see why the DHCP
> part is on the same level as static configuration in the 1st item in
> the list
> 
>     >
>     [Med] It is important in case the client supports many
> mechanisms and receives the information using various sources.
> 

[Med] Done. Thanks.

>     [Med] Would the "Expiry of the certificate of a peer DOTS agent"
> be better? To be honest, I'm not sure to get the issue with the
> initial wording.
> 
> 

[Med] Fixed. 

>     [Med] If multiple names were included, then each of these names
> will be terminating with a byte value of 0. We drafted the text with
> the assumption that the reader is familiar with Section 3.1 of
> RFC1035.
> 
> EV> sure about RFC 1035 ;-) but I wonder whether this part of the
> sentence is useful as the previous part " OPTION_V6_DOTS_RI contains
> more than one name" seems perfectly enough for me so reader may
> wonder about the part " as distinguished by the presence of multiple
> root labels"
> 

[Med] OK to remove it if you think this is obvious.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 4 Nov 2020 15:11:12 +0000

Med,

I guess we are converging about the remaining point, look for EV2>

-----Original Message-----
From: iesg <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Wednesday, 4 November 2020 at 12:48
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>

EV2> What about

OLD TEXT
      Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291])
      are allowed to be included in this option.

NEW TEXT
      Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291])
      MAY to be included in this option when there is no DHCPv4 server able to advertise the DHCPv4 DOTS options and when only IPv4 connectivity is possible to the DOTS server. IPv4-mapped IPv6 addresses MUST NOT be used when there are DHCPv4 servers able to advertise the DHCPv4 DOTS options.

END OF NEW TEXT (the "MUST NOT" may be removed at your convenience)

---

From: <[email-masked]>
Date: Wed, 4 Nov 2020 15:43:44 +0000

Re-,

This helpful. Thanks. 

I went with the proposal but without the last sentence. The changes can be tracked at:
https://tinyurl.com/dots-discovery-iesg

Cheers,
Med

> Envoyé : mercredi 4 novembre 2020 16:11
> Cc : Valery Smyslov <[email-masked]>; Bernie Volz (volz)
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; draft-ietf-dots-server-
> [email-masked]
> From: iesg <[email-masked]> on behalf of
> "[email-masked]" <[email-masked]>
>     >     > I fully second Zhen Cao's review: how will the IPv4-
> mapped
>     > IPv6
>     >     > address(es) be used? They MUST not appear on the wire
> and
>     > there is a
>     >     > available, no DHCPv4, and only IPv4 connectivity to the
> DOTS
>     > server
>     "This is particularly useful in IPv4 service continuity
> deployments (e.g., [RFC6333]) where only DHCPv6 is used and DHCPv4-
> over-DHCPv6 [RFC7341] is not supported."
> 
> EV2> What about
> 
> OLD TEXT
>       MAY to be included in this option when there is no DHCPv4
> server able to advertise the DHCPv4 DOTS options and when only IPv4
> connectivity is possible to the DOTS server. IPv4-mapped IPv6
> addresses MUST NOT be used when there are DHCPv4 servers able to
> advertise the DHCPv4 DOTS options.
>