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. > > 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
