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

[[e-mail]]

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:[e-mail]]
> Envoyé : mardi 3 novembre 2020 19:57
> À : The IESG <[e-mail]>
> Cc : [e-mail]; dots-
> [e-mail]; [e-mail]; Valery Smyslov <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Objet : Éric Vyncke's Discuss on draft-ietf-dots-server-discovery-
> 14: (with DISCUSS and COMMENT)
> 
> É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/
> 

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

> 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).

[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."

> 
> --------------------------------------------------------------------
> --
> 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

[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. 

> 
> -- 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.

[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.

> 
> -- 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 ;-)

[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.