Thank you for the feedback! I’ve responded inline below.
> On Jul 17, 2025, at 8:23 PM, Eric Rescorla <[email protected]> wrote:
>
> Overall, this draft seems clear and useful. I have concerns
> about whether PAKEs will really take off this time, but based on the
> discussion at the last meeting and the various statements of support
> from large deployments, I think we have enough positive information
> to adopt this draft.
>
> Some additional comments below.
>
> TECHNICAL
> S 4.1.
> The client and server identity fields are common to all PAKEShares to
> prevent client enumeration attacks; see Section 8.
>
> Section 8 doesn't really clear this point up. I think that the
> concern you have here is that if:
>
> 1. The identities are per-algorithm
> 2. The server first selects the identity out of the union of the
> identities and then the PAKE algorithm out of the matching
> values.
>
> Then the attacker can provide disjoint identities for each algorithm
> and potentially determine whether an identity exists based on the
> chosen algorithm.
>
> However, the cost of this design is that it does not allow the client
> to express the situation where it has a different set of identities
> for each algorithm and that potentially results in protocol failure.
> Is that possible? If so, then this seems not ideal. If the rule was
> that servers *first* selected the algorithm and then selected the
> identity, would that avoid the enumeration attack?
Requiring servers to first select the algorithm and then select the
identity would avoid the enumeration risk. It is not clear to me at
this point in time whether there is a situation where a client would
need a different set of identities per algorithm, but we are open to
changing this if that flexibility is needed.
> The client MAY also send a pre_shared_key extension along with the
> pake extension, to allow the server to choose an authentication mode.
>
> Is the point here that the server can choose either PAKE or PSK?
> You might state that more directly.
>
>
> S 4.3.
> Is there a technical reason to combine the PAKE secret with the
> ECDHE secret rather than having the PAKE secret take the place
> of the PSK? That seems more natural and then we don't have to
> worry about whether the PAKE secret is fixed length.
Our reasons for combining with the ECDHE secret versus as the PSK input are:
1. PAKEs and ECDHE are both AKEs
2. The PSK input is supposed to be available before the server supplies any
input
(since it would be used to compute the ClientHello binders, for example).
The
PAKE secret is not available until receiving the ServerHello.
> S 6.2.
> The content of the server PAKEShare value in the PAKEServerHello
> structure consists of the PAKEScheme value SPAKE2PLUS_V1 and the
> value shareV || confirmV, i.e., shareV and confirmV concatenated, as
> computed in Section 3.3 of [SPAKE2PLUS].
>
> Are shareV and confirmV fixed length?
For the PAKEScheme value SPAKE2PLUS_V1, the shares are always the same length.
> Given shareP and shareV, the client and server can then both compute
> K_main, the root secret in the protocol as described in Section 3.4
> of [SPAKE2PLUS]. The "Context" value for SPAKE2+ may be specified by
> the application to include additional context in the protocol
> transcript or left empty. See Section 3 of [SPAKE2PLUS]. The rest
>
> I am finding this text confusing. Is the reference to "the application"
> to something that lives above TLS? So does anyone who uses this
> protocol have to specify this?
Yes, “the application” being something that lives above TLS.
The intent here was to have a mitigation for cross-protocol attacks. We are
also open to providing a default TLS specific string or prefix.
>
>
> EDITORIAL
> S 1.
>
> In prior versions of TLS, this functionality has been provided by the
> integration of the Secure Remote Password PAKE protocol (SRP)
>
> Prior to what? I would say.
>
> In versions of TLS prior to TLS 1.3...
>
>
> TLS 1.3 itself provides a mechanism for authentication with pre-
> shared keys (PSKs). However, PSKs used with this protocol need to be
> "full-entropy", because the binder values used for authentication can
> be used to mount a dictionary attack on the PSK. So while the TLS
>
> This is also true if you *just* do PSK w/o certificate authentication.
>
> case, this document defines a concrete protocol for executing the
> SPAKE2+ PAKE protocol [RFC9383].
>
> I would say "a concrete protocol binding".
>
>
> S 4.1.
> Nit. In the definition of PAKEShare, you have:
>
> struct {
> PAKEScheme pake_scheme;
> opaque pake_message<1..2^16-1>;
>
> You are missing a space before "pake_message" on the second line.
>
>
>
>
> S 8.3.
> As with PSK based authentication, if only PAKE authentication is in
> use, then an attacker that learns the low entropy secret could
> impersonate either the client or the server. In situations where a
>
> It might be worth explicitly saying that this is an attack which
> can be mounted by an attacker who steals the server's verifier
> database.
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
