I support adoption, especially given that there exist interoperable implementations.
I have no opinion about whether or not this should define one PAKE, or be generic across multiple PAKEs. On Mon, Jul 28, 2025 at 11:41 AM Eric Rescorla <[email protected]> wrote: > > > On Mon, Jul 28, 2025 at 8:29 AM Christopher Patton <cpatton= > [email protected]> wrote: > >> 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. >> > > I somehow missed this. I agree with Chris that that's a lot of the value > this draft provides and it should be uniform for all PAKEs > > -Ekr > > >> >> 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] >> > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
