Subject: [Last-Call] Tsvart last call review of draft-ietf-dots-server-discovery-11

From: Kyle Rose via Datatracker <[email-masked]>
Date: Sun, 11 Oct 2020 17:09:36 -0700

Reviewer: Kyle Rose
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

>From the perspective of the transport area, this document is Ready: the
specification of new SRV application protocol names appears to comply with
current TSVART guidance.

That said, I have some questions and comments that may or may not be of
interest to the transport ADs:

* Section 4 says:

   The discovery method is reiterated by a DOTS agent upon the following
   events:

   o  Expiry of a a validity timer (e.g., DHCP lease, DNS TTL)
      associated with a discovered DOTS agent.

>From my reading, rendezvous information for the DOTS server is "pushed" to the
client via DHCP, so it's not clear the above is actionable. Is it simply the
case that a client should use the DOTS server assigned in the most recent lease?

* Section 5.1 describes a trust mechanism that can charitably be described as
"hopeful". Fundamentally, the security of TLS relies on a three-legged stool:

    (1) The integrity of the X.509 server certificate issuance procedures
    (2) The cryptographic trust anchors configured in a client
    (3) Pre-established trust in the server's identity, which must match a
    ServerAltName in the signed server certificate

The security considerations section briefly alludes to the problems with using
DHCP via reference to security considerations sections in DHCP RFCs, but I
don't think that quite does justice to the problem here. TLS is cripped by a
failure in any of the above:

    * A trusted CA wrongly issues a certificate to a third party with the
    ability to hijack rendezvous (e.g., through BGP or DNS attacks) * A user's
    certificate store is augmented by a CA under the control of an adversary *
    Via a mistaken or injected hostname, a user establishes a connection to the
    wrong endpoint that nonetheless has a legitimately-issued certificate

Using DHCP, an inherently insecure protocol, to inform DOTS clients of the
hostname of DOTS server knocks this third leg out, calling into question the
entire mechanism. Measures can be taken to mitigate this risk, such as
configuring clients with a domain whitelist (e.g., accept DOTS names only
within a particular domain), configuring clients with a set of private CAs as
trust anchors, configuring border routers with network-layer packet filtering
for DOTS traffic, etc., but ultimately without some preconfiguration, clients
are at the mercy of rogue DHCP.

* Section 5.2.1 has:

   The DHCPv4 [RFC2132] DOTS Reference Identifier option is used to
   configure a name of the peer DOTS agent.  The format of this option
   is illustrated in Figure 6.

            Code  Length   Peer DOTS agent name
           +-----+-----+-----+-----+-----+-----+-----+--
           |TBA3 |  n  |  s1 |  s2 |  s3 |  s4 | s5  |  ...
           +-----+-----+-----+-----+-----+-----+-----+--

     The values s1, s2, s3, etc. represent the domain name labels in the
     domain name encoding.

Is the final label zero-length? Other parts of the DHCPv4 protocol terminate
domain names with a zero-length label. What if a zero-length label appears in
some s_i other than the final one?

* Section 7 says:

   This document does not define any keys; the TXT record of a DNS-SD
   service is thus empty (Section 6 of [RFC6763]).

RFC 6763 says that an empty TXT record MUST be included alongside the SRV
record where DNS-SD is concerned. Should normative language be used here, or
should we rely on the normative reference in case that guidance changes in the
future?

---

From: <[email-masked]>
Date: Tue, 13 Oct 2020 08:28:51 +0000

Hi Kyle, 

Thank you for the review.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Kyle Rose via Datatracker [mailto:[email-masked]]
> Envoyé : lundi 12 octobre 2020 02:10
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; draft-ietf-dots-server-
> [email-masked]
> Objet : Tsvart last call review of draft-ietf-dots-server-discovery-
> 11
> 
> Reviewer: Kyle Rose
> This document has been reviewed as part of the transport area review
> team's ongoing effort to review key IETF documents. These comments
> were written primarily for the transport area directors, but are
> copied to the document's authors and WG to allow them to address any
> issues raised and also to the IETF discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider
> this review as part of the last-call comments they receive. Please
> always CC [email-masked] if you reply to or forward this review.
> 
> specification of new SRV application protocol names appears to
> comply with current TSVART guidance.
> 

[Med] Thanks. 

> That said, I have some questions and comments that may or may not be
> of interest to the transport ADs:
> 
> * Section 4 says:
> 
> >From my reading, rendezvous information for the DOTS server is
> "pushed"
> >to the
> client via DHCP, so it's not clear the above is actionable. Is it
> simply the case that a client should use the DOTS server assigned in
> the most recent lease?
> 

[Med] The intent is to avoid using "stale" servers. So yes, this is about using the server that was most recently discovered but also about not using a server beyond a validity time associated with the discovered server. 

> * Section 5.1 describes a trust mechanism that can charitably be
> described as "hopeful". Fundamentally, the security of TLS relies on
> a three-legged stool:
> 
> The security considerations section briefly alludes to the problems
> with using DHCP via reference to security considerations sections in
> DHCP RFCs, but I don't think that quite does justice to the problem
> here. TLS is cripped by a failure in any of the above:
> 
> Using DHCP, an inherently insecure protocol, to inform DOTS clients
> of the hostname of DOTS server knocks this third leg out, calling
> into question the entire mechanism.

[Med] We didn't include such discussion as this is a variation of agent impersonation (covered by the pointer to RFC8811) and rogue servers in RFC8415. Also, we have the following:

   This document assumes that security credentials to authenticate DOTS
   server(s) are provisioned to a DOTS client using a mechanism such as
   (but not limited to) those discussed in [RFC8572] ...

We can add some text to elaborate on this further. 

 Measures can be taken to
> mitigate this risk, such as configuring clients with a domain
> whitelist (e.g., accept DOTS names only within a particular domain),
> configuring clients with a set of private CAs as trust anchors,
> configuring border routers with network-layer packet filtering for
> DOTS traffic, etc., but ultimately without some preconfiguration,
> clients are at the mercy of rogue DHCP.
> 
> * Section 5.2.1 has:
> 
> Is the final label zero-length?

[Med] Yes, as indicated in 5.2.1: 

   o  Peer DOTS agent name: The domain name of the peer DOTS agent.
      This field is formatted as specified in Section 10 of [RFC8415]. 

 Other parts of the DHCPv4 protocol
> terminate domain names with a zero-length label. What if a zero-
> length label appears in some s_i other than the final one?
> 

[Med] Names are validated as per the rules in Section 10 of RFC8415:  

   If the DHCP client receives OPTION_V4_DOTS_RI only, but
   OPTION_V4_DOTS_RI option contains more than one name, as
   distinguished by the presence of multiple root labels, the DHCP
   client MUST use only the first name.  Once the name is validated
   (Section 10 of [RFC8415]), the name is passed to a name resolution
   library.

> RFC 6763 says that an empty TXT record MUST be included alongside
> the SRV record where DNS-SD is concerned. Should normative language
> be used here, or should we rely on the normative reference in case
> that guidance changes in the future?

[Med] I don't think that the use of normative language is needed here. RFC6763 is sufficient by its own.

_________________________________________________________________________________________________________________________

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: Kyle Rose <[email-masked]>
Date: Wed, 21 Oct 2020 10:23:33 -0400

> [Med] The intent is to avoid using "stale" servers. So yes, this is about using the server that was most recently discovered but also about not using a server beyond a validity time associated with…

I think the wording for this requirement should be normative rather
than buried in the description of the discovery mechanism. Adding a
statement somewhere that "a DOTS agent MUST NOT initiate or continue
communicating with a server whose associated discovery metadata has
expired: for instance, once a DNS TTL or DHCP lease has expired, an
appropriate DOTS server must be rediscovered using one of the
mechanisms in {}."

> We can add some text to elaborate on this further.

No, I think this is fine as-is. I think I just missed these references to 8572.

>    (Section 10 of [RFC8415]), the name is passed to a name resolution

Got it. It's a roundabout way of saying "ignore everything after the
first zero-length label". I'm guessing this is well-understood by the
DNS community.

> [Med] I don't think that the use of normative language is needed here. RFC6763 is sufficient by its own.

Sounds good.

Thanks for the follow-up. My apologies for the delay in responding.

Kyle

---

From: <[email-masked]>
Date: Wed, 21 Oct 2020 15:00:09 +0000

Hi Kyle, 

Please see inline.

Cheers,
Med

> De : Kyle Rose [mailto:[email-masked]]
> Envoyé : mercredi 21 octobre 2020 16:24
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : [email-masked]; [email-masked]; [email-masked]; draft-
> [email-masked]
> Objet : Re: Tsvart last call review of draft-ietf-dots-server-
> discovery-11
> 
> > [Med] The intent is to avoid using "stale" servers. So yes, this
> is about using the server that was most recently discovered but also
> about not using a server beyond a validity time associated with the
> discovered server.
> 

[Med] The normative language is not used because managing sessions is beyond discovery. Such behavior will depend on the DOTS channel and whether a DOTS agent is in idle or attack time. For example, immediately closing a communication with a peer DOTS agent while an attack mitigation is in progress may not be convenient. We have such exceptions in RFC8782, e.g.,

   "This fallback mechanism is triggered immediately upon
   expiry of the TTL, except when a DDoS attack is active."

> appropriate DOTS server must be rediscovered using one of the

FWIW, your review was taken into account in https://tools.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery-12.txt. See the security section, in particular. 

Thank you.