This is a digression, but I've heard a few people mention SAS: SAS requires a very different UX from PAKE, worse for both users and security. SAS is about post-hoc confirmation of a handshake-specific value, which means:
1. You need a way to at least display, if not input, dynamic data on both sides of the transaction. As opposed to say printing something on the outside of a device and scanning it from the other. 2. Users need to compare these dynamic values 3. If the user skips or mis-compares the values, the handshake succeeds PAKE requires less capability in the devices and less work from the user, and fails safe in the event of user error. On Mon, Jul 28, 2025 at 1:24 AM Dennis Jackson <ietf= [email protected]> wrote: > I support adoption. > > I'm somewhat skeptical there's a device pairing scenario in which PAKEs > are worth the investment over SAS, but it seems like there's plenty of > folks interested in deploying this and I can see the value in getting it > right. > > On 24/07/2025 08:01, Sean Turner wrote: > > At IETF 122 & 123 we discussed draft-bmw-tls-pake13 [0]. The sense of > room @ both sessions was that there was support for working on PAKEs in TLS. > > > > This email starts the WG adoption call for draft-bmw-tls-pake13. If you > support adoption and are willing to review and contribute text, please send > a message to the list. If you do not support adoption of this draft, please > send a message to the list and indicate why. This call will close at 2359 > UTC on 07 August 2025. > > > > Cheers, > > Deirdre, Joe, and Sean > > > > [0] https://datatracker.ietf.org/doc/draft-bmw-tls-pake13/ > > > > _______________________________________________ > > 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]
