Hi, I watched the meeting on YouTube. It seems like it went pretty well.
SSL/TLS has improved over the years. We don't advise use of SSL3 or TLS 1.0 anymore. PAKEs are the same. They get better. The comments along the lines of "have the chairs checked" or "run up against the PAKE wall" or "we've tried this before" are indirect. The problem with these PAKE ideas is that they work. What everyone fears will happen is that the draft will go all the way through the process, only to be met by an IPR disclosure. It will be something like "Northcom Telstar Logistics Business Company". That is just the government using a chilling effect. Maybe it is different this time around, but I am not optimistic. thanks, Rob On Mon, Mar 17, 2025 at 7:23 PM Laura Bauman <l_bau...@apple.com> wrote: > > On Mar 18, 2025, at 1:44 AM, Rob Sayre <say...@gmail.com> wrote: > > On Mon, Mar 17, 2025 at 10:02 AM Rob Sayre <say...@gmail.com> wrote: > >> On Mon, Mar 17, 2025 at 9:38 AM Eric Rescorla <e...@rtfm.com> wrote: >> >>> >>> 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. >>> >> >> In my mind, the idea is that you don't have to rely solely on WebPKI if >> you have that information handy after registration. >> > > The other PAKE draft on the agenda explains this motivation better in its > introduction, although the mechanism is different: > > > https://www.ietf.org/archive/id/draft-guo-pake-pha-tls-01.html#name-introduction > > In draft-bmw-tls-pake13-01, the words "such as" are doing a lot of work in > the abstract and introduction. I doubt they are aiming at passwords that a > user types, given all of their other efforts to ditch passwords, but idk. > > > Our usage of “password” in the abstract/introduction appears to be a bit > misleading. There is a disconnect between the term password (as in > P(assword)AKE) and what we view as the motivating use cases for this > mechanism, namely: > > 1. One time connections with no need for a long term authentication > credentials (e.g. screen casting, video conferencing equipment) > 2. An initial connection over which high entropy long term credentials > (e.g. external PSK, RPKs) can be exchanged (e.g. pairing, device setup) > > In these cases, the “password” is more likely to be a passcode/pin or > otherwise temporary low entropy secret. We are not aiming to provide a > solution or alternative for web login use cases or advocating for users to > need to enter passwords more places. >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
