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. 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
