On Mon, Mar 17, 2025 at 6:17 AM Eric Rescorla <e...@rtfm.com> wrote:
> On Sun, Mar 16, 2025 at 11:52 AM Rob Sayre <say...@gmail.com> wrote: > >> On Sat, Mar 15, 2025 at 7:21 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. >>> >> >> I'm pretty sure this is not news to authors, but I've thought about this >> one before (when the IRTF was conducting their PAKE contest). It seems like >> using both PAKE and certificates together, in combination with "Sign In" >> products would be pretty powerful. I am not sure why this draft needs TLS >> extensions, and it doesn't cover the thorny problem of PAKE registration at >> all. >> > > Leaving the question of registration aside, I don't believe that PAKEs are > really viable in the Web context, for two reasons: > > - Sites in general want to control the login experience and this means > having the password typed in in a box they control, not in the browser UI, > especially given the current terrible state of password UIs for browsers. > - In the phishing context, the attacker site can just prompt the user > directly for their password or simulate the PAKE UI, thus bypassing the > PAKE. The whole premise of phishing is that the user doesn't check > carefully, so I don't think we can rely on users to detect this form of > attack. > > We already have phishing resistant authentication mechanisms such as > WebAuthn which don't have this problem, so I think the motivation for PAKEs > on the Web is pretty weak. > 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.) Each run of the PAKE gives the peer a chance to guess our low-entropy secret. That means, from what I can tell, the ideal flow is for your application to have some kind of one-time or infrequent password auth flow that it actually runs the PAKE, and then that gives you a more robust higher-entropy secret that can be used for subsequent operations if you need that (e.g. for new connections). While applications often have flows like this (login with password that establishes some cookie-like credential from there, some sort of pairing ceremony, etc.), a connection-based PAKE story needs the logic for those flows to be close enough to be sufficiently close to the application logic to capture that. Over something like HTTP, and particularly on the web where you can't break through the HTTP request/response abstraction, that sort of thing doesn't work out. If your application works in terms of HTTP requests and responses, HTTP connection creation is an internal detail of your HTTP stack. It's all part of a big black box that tries to effectively manage the sea of HTTP requests made by the application. HTTP client stacks will do all kinds of things like open connections in parallel, pool them, predictively connect them, etc. Different HTTP versions have very different kinds of connection reuse capabilities. We keep inventing ways for servers to influence connection management for load balancing, etc. This is similar to why TLS client certificates has worked badly for authenticating humans, who have to make decisions on the fly which hat they're wearing, what information to reveal, etc.. So *if* someone wants to do PAKE in *that* environment, something with HTTP as the substrate would work better. Whereas if your application is a bit closer to the TLS side, then doing it in TLS can make sense. (But I would also agree that WebAuthn seems a better direction for web-like stuff. That seems to have a lot more energy and existing deployment behind it, and some additional nice properties.) > 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? > > -Ekr > > > > >> I decided not to work on this problem, because I figured it would make a >> lot of people mad, and I didn't want to spend my time on it. But, might as >> well ask the question since we have this draft in front of us. >> >> thanks, >> Rob >> >> >> _______________________________________________ >> 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
