search

chris-wood / draft-bmw-tls-pake13

Other
2 stars 0 forks source link

State properties required for PAKES used #4

Open menonsamir opened 4 days ago

menonsamir commented 4 days ago

From IETF discussion with @BjoernMHaase and @FrankXL:

We should state explicitly what properties a PAKE must have to be eligible for use under this extension (and registered as a NamedPAKE).

The main one we've discussed so far is that the PAKE should be compatible with performing key confirmation through the standard TLS 1.3 Finished message.

BjoernMHaase commented 3 days ago

Yes I agree. I don't see any property except for the fact that the last PAKE protocol message needs to only include a key confirmation.

We also should be having a security consideration paragraph per protocol with an analysis on how the security analysis of the PAKE protocol is covering the security analysis of the interleaved TLS and PAKE construction.

chris-wood commented 2 days ago

I don't know if we need to say anything here, since the extension doesn't dictate how the PAKE updates the TLS key schedule. That's left to each named PAKE. For example, it could be the case that, with SPAKE2+, the TLS key schedule is modified with the key confirmation messages (confirm_P or confirm_V), whereas for with CPace the TLS key schedule could be modified with the output shared secret. (I'm not saying that we should do this for SPAKE2+, but using it as an example to show that the extension isn't imposing requirements on the underlying PAKE in this manner.)

If anything, the extension restricts the underlying PAKE to one in which client and server negotiate with identities and PAKE messages, but that covers basically anything.