On Mon, Mar 17, 2025 at 9:22 AM Rob Sayre <say...@gmail.com> wrote:
> > > On Mon, Mar 17, 2025 at 8:49 AM Eric Rescorla <e...@rtfm.com> wrote: > >> >> >> 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. >> > > Yes, this is the current experience. > > >> 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. >> > > Well, with that flow above, the user doesn't type their password. It looks > like this: > https://youtu.be/TmS66WNL1GE?si=pkEcjcPg1YdnDbSb&t=196 > Well, yes, but that's because this is a third party login system, so it's qualitatively different from password systems. The idea with a PAKE is to bootstrap the existing trust relationships (i.e., the pairwise password) onto a safer technological base. I'm not saying that third party authentication isn't valuable, but we already have that without PAKEs. The implicit problem statement here is how to provide a more secure primary authentication experience. > >> 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? >> > > In that ladder diagram in the link above, both sides have enough > information to bootstrap a PAKE, but the acronym is a bit of a misnomer in > this case. So, the PAKE registration process is the existing "Sign In / > Sign Up" feature. Then that data is used in the TLS handshake, but you only > need an identifier in the ClientHello to get started, because you've > verified their tokens during registration. This way is much less general > than this draft, and assumes that kind of sign-in flow. But, it's a pretty > popular pattern. > As above, I don't see what this has to do with PAKEs at all. If you have a third party authentication system, whether sign in with Apple, Google, or some SSO provider, then you don't need to share any secret with the relying party. -Ekr
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
