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

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: TLS <[e-mail]> On Behalf Of Christopher Wood
> Sent: Wednesday, April 22, 2020 1:10 PM
> To: [e-mail]
> Subject: [EXTERNAL] Re: [TLS] Comments on draft-dt-tls-external-psk-
> guidance-01
>
> 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.

Agreed.

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

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

OK.

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

Yes.

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

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