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 <e...@rtfm.com> wrote: > > > On Mon, Jul 28, 2025 at 8:29 AM Christopher Patton <cpatton= > 40cloudflare....@dmarc.ietf.org> 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 -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org >> > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
