On Mon, Mar 17, 2025 at 8:37 AM Rob Sayre <say...@gmail.com> wrote:
> On Sun, Mar 16, 2025 at 7:52 PM David Benjamin <david...@chromium.org> > wrote: > >> >> I'd also add that, *if* we want something PAKE-shaped in a web-like >> context, I don't think TLS-PAKE is a good fit for it. (Which is fine! Not >> everything needs to be for every use case.) >> > > Yes, I was thinking of mobile phone sign-in use cases. I think web > browsers could also offer "native" sign-in UI for people that want to use > it. It wouldn't be much different from my bank iOS app that lets me sign in > with FaceID. This kind of thing: > > > https://developer.apple.com/documentation/sign_in_with_apple/authenticating-users-with-sign-in-with-apple > The current workflow is that the user goes to example.com, which prompts them for their password. They then type their password into some form. With PAKE, what we want them to do is at this point to instead type it into some browser affordance, so that the site never sees the password. As I said previously, this is technically straightforward but also phishable because training users to only type the password into the browser chrome is very difficult. Can you explain specifically the experience you have in mind that you think would avoid that risk? > Couldn't it be click "Sign In", and start the TLS key schedule from there, >>>> instead of "0"? No extensions necessary. >>>> >>> >>> Regardless of the point above, I do not believe this would work. You >>> need some protocol to carry the PAKE information and if that's not going in >>> the TLS handshake, where is it going? >>> >> > Oh, right. I had some scheme to carry it in another extension (I think I > tried a few) with the aim of "Do Not Stick Out", but it occurs to me that, > these days, you could put these only inside the ECH ClientHelloInner if you > don't want it to be obvious that you're using a PAKE. > Note that this stanza is in response to me, not davidben. -Ekr > > thanks, > Rob > >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
