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

[Christopher Wood <[e-mail]>]

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

On Mon, Apr 20, 2020, at 7:26 AM, Hollenbeck, Scott wrote:
> 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."

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

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