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?
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.
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?
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?
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 -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
