I wanted to follow up on this specific use case but don't want to
pollute the PAKEs adoption thread where I already indicated support for
adoption.
On 29/07/2025 21:30, Richard Barnes wrote:
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.
I think this is quite a bit more nuanced than you suggest, but I do
recognize there are some scenarios with low-capability devices where
PAKEs provide a small benefit.
If at least one device (A) has a display and the other device (B) has an
input mechanism, PAKEs and SAS provide equivalent UX. You display the
SAS (or PAKE key) on A and ask the user to enter it on B. B rejects if
the entry doesn't match the SAS or the PAKE KEX fails. The UX and
security is identical.
If A and B only have displays, you can do SAS but not a PAKE.
If A and B only have input mechanisms, you can do a PAKE but not SAS.
If A has neither a display nor an input mechanism, then you're down to a
hardcoded secret which needs to be entered on B. If you can use a PAKE,
it can be a low entropy secret. Otherwise, it needs to be high entropy.
In both cases, you'd want to offer it via barcode, QR code, NFC or
whatever. I recognize PAKEs make for a marginally nicer UX in this
scenario, but it'd be even nicer not to ship devices with hardcoded secrets.
On Mon, Jul 28, 2025 at 1:24 AM Dennis Jackson
<ietf=40dennis-jackson...@dmarc.ietf.org> 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.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
