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
