On Tue, Jul 22, 2025 at 12:35 AM Eric Rescorla <e...@rtfm.com> wrote:
> On Mon, Jul 21, 2025 at 7:08 AM Laura Bauman <l_bau...@apple.com> wrote: > >> Thank you for the feedback! I’ve responded inline below. >> >> > On Jul 17, 2025, at 8:23 PM, Eric Rescorla <e...@rtfm.com> 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. >> > > Generally, I think it's better to err on the side of flexibility > but this is a question the WG can determine if this draft > is adopted. > > > >> >> > 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. >> > > I see your point here, but I'm not sure I'm persuaded. However, again > this is something the WG could sort out. However, with this structure, > I think you either need to: > > 1. Say that all PAKEs must emit a fixed-length value. > 2. Have an encoding that includes the length. > I don't have any particular thoughts right now on the rest of it, but I think, of those, (1) is the way to go. If your output secret is variable-length, your system probably has a timing side channel anyway. (E.g. https://raccoon-attack.com/) Similarly, hybrid key shares can use plain concatenation without any fuss. (If somehow someone does have a non-broken variable-length PAKE output, we can always say that *that* PAKE's output gets a length prefix before concatenating. But this is silly and won't happen.) > > 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. > > > This seems like a job for ALPN, rather than inventing something bespoke > for PAKEs. > > -Ekr > > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
