I agree we shouldn't *disable* key_share, but it seems like the right answer here is to instead combine the PAKE output with the existing key establishment.
-Ekr On Mon, Mar 24, 2025 at 7:56 AM Christopher Patton <cpatton= 40cloudflare....@dmarc.ietf.org> wrote: > I've read the draft and support doing this. However, I wanted to +1 > Martin's suggestion of restricting this to 2-move PAKEs (1 round trip) if > possible, and if so, defining a new key_share rather than a new extension > that disables key_share. It seems like this would be a much simpler design. > > Chris P. > > On Sat, Mar 15, 2025 at 7:22 PM Laura Bauman <l_bauman= > 40apple....@dmarc.ietf.org> wrote: > >> Thanks to everyone that has taken a look at draft-bmw-tls-pake13-01.txt >> and provided feedback so far. As more people start reading it, I wanted to >> clarify that the current draft version does not yet reflect the change we >> intend to make to allow Certificates and the pake extension to be used >> together. We’ve filed a GitHub issue here tracking our intent to change >> this: https://github.com/chris-wood/draft-bmw-tls-pake13/issues/25. >> >> Thanks, >> >> Laura Bauman >> l_bau...@apple.com >> _______________________________________________ >> 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
