Subject: [TLS] Comments on draft-dt-tls-external-psk-guidance-01

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 20 Apr 2020 14:26:25 +0000

Here are a few comments gathered from Verisign Labs on draft-dt-tls-external-psk-guidance-01:

1.  Sec. 6, requirement  1 states "Low entropy keys are only secure against active attack if a Password Authenticated Key Exchange (PAKE) is used with TLS."  "only secure ... if" may be too strong a statement, because there could be other mechanisms for increasing the entropy of a pre-shared key that do not meet the formal definition of a PAKE.  Moreover, as defined in draft-barnes-tls-pake, a PAKE repurposes the DH key share to carry a transformed version of the EPSK, so it involves a different architecture than the ordinary process for incorporating EPSKs into the TLS key schedule that is assumed in most of the present draft.

If the goal of the present draft is to encompass PAKEs as well as the ordinary process, then the scope of the draft should be broadened to something like "handshakes based on EPSKs, whether through the ordinary process  of incorporating them into the key schedule, or through alternate mechanisms such as PAKE where the DH key share is based on the EPSK."

Alternatively, the statement in requirement 1 could be rephrased as follows:

"If only low-entropy keys are available, then key establishment mechanisms such as Password Authenticated Key Exchange (PAKE) that mitigate the risk of offline dictionary attacks MUST be employed.  Note that these mechanisms do not necessarily follow the same architecture as the ordinary process for incorporating EPSKs described in this draft."

2. Sec. 6, requirement 2 states, "Each PSK MUST NOT be shared between with more than two logical nodes."  This "MUST NOT" is stronger than the "NOT RECOMMENDED to share the same PSK between more than one client and server"
In Sec. 7 and would exclude group PSK use cases that are acknowledged in that section.  The requirement is also inconsistent with this statement in Appendix B of draft-ietf-tls-external-psk-importer:

"Applications which require authenticating finer-grained roles while still configuring a single shared PSK across all nodes can resolve this mismatch either by exchanging roles over the TLS connection after the handshake or by incorporating the roles of both the client and server into the IPSK context string."

If the intent is to restrict use to at most two nodes, then requirement 2 should go even further and restrict use to one node in a TLS client role, and one in a TLS server role.

We would therefore suggest that requirement 2 be changed to something like the following:

"Unless other accommodations are made, each PSK MUST be restricted in its use to at most two logical nodes:  one logical node in a TLS client role and one logical node in a TLS server role.  (The two logical nodes MAY be the same, in different roles.)  Two acceptable accommodations are described in [draft-ietf-tls-external-psk-importer]:  exchanging client and server identifiers  over the TLS connection after the handshake; and incorporating identifiers  for both the client and the server into the context string for an EPSK importer."

(Note that we've changed "roles" to "identifiers" to align with Sec. 7)

Related to this, "logical node" should be defined somewhere, e.g., "For purposes of this document, a logical node is a computing presence that other parties can interact with via the TLS protocol.  A logical node could potentially be realized with multiple physical instances operating under common administrative control, e.g., a server farm."  Alternatively, the term "endpoint," which is used elsewhere in this document, could be used here as well (perhaps also avoiding the single use of "agent").

3.  Sec. 7 recommends that that each node selects one globally unique identifier for all PSK handshakes, but without giving rationale why this approach is preferred for mitigating the attacks mentioned earlier in the section.  This may be limiting, because a logical node may legitimately be known to different endpoints by different identifiers:  a domain name in some cases, an IPv4 address in other cases, and an IPv6 address in still other cases.  We would therefore recommend relaxing this recommendation.

4.  General.  The draft makes no mention of certificate-based authentication in connection with EPSKs, for instance as described in in RFC 8773, "TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key."  We understand that use of external PSKs with certificates is out of scope for the design team.  Certificate-based authentication, potentially in combination with a DH exchange, can improve the security properties of TLS handshakes based on EPSKs and help protect against both rerouting attacks and impersonation attacks.  Is there any interest in adding some guiding text to the document before it's adopted by the WG?  We're willing to provide text for consideration.

Scott

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 22 Apr 2020 10:09:54 -0700

Thanks for the feedback, Scott. Please see inline below.

On Mon, Apr 20, 2020, at 7:26 AM, Hollenbeck, Scott wrote:
> 1.  Sec. 6, requirement  1 states "Low entropy keys are only secure 
> against active attack if a Password Authenticated Key Exchange (PAKE) 
> is used with TLS."  "only secure ... if" may be too strong a statement, 
> because there could be other mechanisms for increasing the entropy of a 
> pre-shared key that do not meet the formal definition of a PAKE.  
> Moreover, as defined in draft-barnes-tls-pake, a PAKE repurposes the DH 
> key share to carry a transformed version of the EPSK, so it involves a 
> different architecture than the ordinary process for incorporating 
> EPSKs into the TLS key schedule that is assumed in most of the present 
> draft.
> 
> If the goal of the present draft is to encompass PAKEs as well as the 
> ordinary process, then the scope of the draft should be broadened to 
> something like "handshakes based on EPSKs, whether through the ordinary 
> process  of incorporating them into the key schedule, or through 
> alternate mechanisms such as PAKE where the DH key share is based on 
> the EPSK."
> 
> "If only low-entropy keys are available, then key establishment 
> mechanisms such as Password Authenticated Key Exchange (PAKE) that 
> mitigate the risk of offline dictionary attacks MUST be employed.  Note 
> that these mechanisms do not necessarily follow the same architecture 
> as the ordinary process for incorporating EPSKs described in this 
> draft."

This seems like a reasonable proposal to me. Specifying integration with PAKEs is (or was intended to be) out of scope, and this clarifies the requirement without widening the scope.

> 2. Sec. 6, requirement 2 states, "Each PSK MUST NOT be shared between 
> with more than two logical nodes."  This "MUST NOT" is stronger than 
> the "NOT RECOMMENDED to share the same PSK between more than one client 
> and server"
> In Sec. 7 and would exclude group PSK use cases that are acknowledged 
> in that section.  The requirement is also inconsistent with this 
> statement in Appendix B of draft-ietf-tls-external-psk-importer:
> 
> "Applications which require authenticating finer-grained roles while 
> still configuring a single shared PSK across all nodes can resolve this 
> mismatch either by exchanging roles over the TLS connection after the 
> handshake or by incorporating the roles of both the client and server 
> into the IPSK context string."
> 
> If the intent is to restrict use to at most two nodes, then requirement 
> 2 should go even further and restrict use to one node in a TLS client 
> role, and one in a TLS server role.
> 
> "Unless other accommodations are made, each PSK MUST be restricted in 
> its use to at most two logical nodes:  one logical node in a TLS client 
> role and one logical node in a TLS server role.  (The two logical nodes 
> MAY be the same, in different roles.)  Two acceptable accommodations 
> are described in [draft-ietf-tls-external-psk-importer]:  exchanging 
> client and server identifiers  over the TLS connection after the 
> handshake; and incorporating identifiers  for both the client and the 
> server into the context string for an EPSK importer."
> 

This is a *great* suggestion! Thank you for clarifying in ways we could not. I'll take it. 

> 
> Related to this, "logical node" should be defined somewhere, e.g., "For 
> purposes of this document, a logical node is a computing presence that 
> other parties can interact with via the TLS protocol.  A logical node 
> could potentially be realized with multiple physical instances 
> operating under common administrative control, e.g., a server farm."  
> Alternatively, the term "endpoint," which is used elsewhere in this 
> document, could be used here as well (perhaps also avoiding the single 
> use of "agent").

Yep, defining "logical node" would be great. We should probably have a separate definition section up front to consolidate these terms in one place. We can work with your suggestions and make that happen.

> 3.  Sec. 7 recommends that that each node selects one globally unique 
> identifier for all PSK handshakes, but without giving rationale why 
> this approach is preferred for mitigating the attacks mentioned earlier 
> in the section.  This may be limiting, because a logical node may 
> legitimately be known to different endpoints by different identifiers:  
> a domain name in some cases, an IPv4 address in other cases, and an 
> IPv6 address in still other cases.  We would therefore recommend 
> relaxing this recommendation.

Since it's merely a recommendation, I think we ought to keep it. It's a simple deployment model that solves issues. 

We could list your use case as a counter example as to when this recommendation may not be appropriate. Would that work?
 
> 4.  General.  The draft makes no mention of certificate-based 
> authentication in connection with EPSKs, for instance as described in 
> in RFC 8773, "TLS 1.3 Extension for Certificate-based Authentication 
> with an External Pre-Shared Key."  We understand that use of external 
> PSKs with certificates is out of scope for the design team.  
> Certificate-based authentication, potentially in combination with a DH 
> exchange, can improve the security properties of TLS handshakes based 
> on EPSKs and help protect against both rerouting attacks and 
> impersonation attacks.  Is there any interest in adding some guiding 
> text to the document before it's adopted by the WG?  We're willing to 
> provide text for consideration.

Sure, we're absolutely open to contributions! You're right that it's out of scope, though it could be useful in an appendix, or wherever else you think it's appropriate.

Best,
Chris

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 23 Apr 2020 15:15:59 +0000

> -----Original Message-----
> From: TLS <[email-masked]> On Behalf Of Christopher Wood
> Sent: Wednesday, April 22, 2020 1:10 PM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [TLS] Comments on draft-dt-tls-external-psk-
> guidance-01
>
> > is used with TLS."  "only secure ... if" may be too strong a
> > statement, because there could be other mechanisms for increasing the
> > entropy of a pre-shared key that do not meet the formal definition of a
> PAKE.
> > Moreover, as defined in draft-barnes-tls-pake, a PAKE repurposes the
> > DH key share to carry a transformed version of the EPSK, so it
> > involves a different architecture than the ordinary process for
> > incorporating EPSKs into the TLS key schedule that is assumed in most
> > of the present draft.
> >
> > something like "handshakes based on EPSKs, whether through the
> > ordinary process  of incorporating them into the key schedule, or
> > through alternate mechanisms such as PAKE where the DH key share is
> > based on the EPSK."
> >
> > mitigate the risk of offline dictionary attacks MUST be employed.
> > Note that these mechanisms do not necessarily follow the same
> > architecture as the ordinary process for incorporating EPSKs described
> > in this draft."
>
> This seems like a reasonable proposal to me. Specifying integration with
> PAKEs is (or was intended to be) out of scope, and this clarifies the
> requirement without widening the scope.

Agreed.

> > the "NOT RECOMMENDED to share the same PSK between more than one
> > client and server"
> > still configuring a single shared PSK across all nodes can resolve
> > this mismatch either by exchanging roles over the TLS connection after
> > the handshake or by incorporating the roles of both the client and
> > server into the IPSK context string."
> >
> > its use to at most two logical nodes:  one logical node in a TLS
> > client role and one logical node in a TLS server role.  (The two
> > logical nodes MAY be the same, in different roles.)  Two acceptable
> > accommodations are described in
> > [draft-ietf-tls-external-psk-importer]:  exchanging client and server
> > identifiers  over the TLS connection after the handshake; and
> > incorporating identifiers  for both the client and the server into the context
> string for an EPSK importer."
> >

Glad to be able to add clarity here.

> > Related to this, "logical node" should be defined somewhere, e.g.,
> > "For purposes of this document, a logical node is a computing presence
> > that other parties can interact with via the TLS protocol.  A logical
> > node could potentially be realized with multiple physical instances
> Yep, defining "logical node" would be great. We should probably have a
> separate definition section up front to consolidate these terms in one place.
> We can work with your suggestions and make that happen.

OK.

> > this approach is preferred for mitigating the attacks mentioned
> > earlier in the section.  This may be limiting, because a logical node
> > may legitimately be known to different endpoints by different identifiers:
> We could list your use case as a counter example as to when this
> recommendation may not be appropriate. Would that work?

Yes.

> Sure, we're absolutely open to contributions! You're right that it's out of
> scope, though it could be useful in an appendix, or wherever else you think
> it's appropriate.

We'd recommend adding a sentence to the introduction that certificate-based authentication is out of scope, with a reference to RFC 8773 for details.  This could be combined with a statement that PAKE is also outside of scope.  Suggestion:

 "The design team effort that produced this document was limited in scope to the PSK techniques specified in TLS 1.3 when using high-entropy PSKs.  Other approaches can also be beneficial in certain situations, but were out of scope.  For example, Password Authenticated Key Exchange (PAKE) techniques [[ref]] can be used to establish a TLS session with low-entropy PSKs, and certificate-based authentication can be combined with PSKs (and possibly with a Diffie-Hellman exchange) to help protect against both rerouting attacks and impersonation attacks [RFC 8773]."

Scott