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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
