I support adoption and am willing to review. My only remaining concern, which can be addressed after adoption, has to do with how the integration of a given PAKE is specified. The draft covers everything I would want it to cover, with one exception: each PAKE would be required to specify how it changes the key schedule (Section 4.3). Is there any particular reason for this? It would be better if the draft specified the key schedule change itself.
Also, thanks to the authors for restricting the compatible PAKEs to two messages! I think this will make our lives a lot easier. The only wrinkle is that many PAKEs we want, like CPace and OPAQUE, have three messages instead of two. But it seems to me that this third message is more often than not an artifact of security analysis and only used for key confirmation. I think our collective intuition here is that the TLS 1.3 handshake already provides this, but I think we should try to confirm this intuition as part of the FATT process. Best, Chris P.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
