Open menonsamir opened 2 weeks ago
The client identity used for PAKE may actually also contain information that should be kept confidential, such as user names in case of human users.
Ideally, we should be preparing the option of having an optional method for encryption of such data. However, I believe that we cannot fully cover that on the level of TLS alone. The way to go here might be to have an alternative approach using the EAP option.
The client identity used for PAKE may actually also contain information that should be kept confidential, such as user names in case of human users.
Encrypting the PAKE information is an orthogonal problem, and one that's already solved by ECH, so we don't need to do anything special for that.
Regarding the identities themselves, I don't think we need to support identity "negotiation" as @bifurcation's suggestion seems to hint at. Clients will know what server identity they wish to connect to, as it's the one that was established offline during registration. I think we should keep the identity encoding as-is on the wire, since ultimately it's up to the application to make sense of the identities when authenticating the handshake.
The client identity and server identity do not seem to be PAKE-specific, because they are often specified by the application. For example, when a client wishes to connect to a server through this PAKE extension, the server identity is determined and the client needs to choose one identity that he/she wants to login no matter which PAKE algorithm is used in this connection. Therefore, can the client identity and server identity be regarded as common fields for this PAKE extension.
From IETF discussion with @BjoernMHaase, @FrankXL, and @bifurcation:
There were several requests to clarify the purpose of client and server identities, and suggestions on how they should be negotiated.
Several overlapping ideas have been suggested so far:
Let's kick off discussion on this topic here.