> -----Original Message----- > From: TLS <tls-boun...@ietf.org> On Behalf Of Christopher Wood > Sent: Wednesday, April 22, 2020 1:10 PM > To: TLS@ietf.org > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
