> On Mar 18, 2025, at 1:44 AM, Rob Sayre <[email protected]> wrote:
>
> On Mon, Mar 17, 2025 at 10:02 AM Rob Sayre <[email protected]
> <mailto:[email protected]>> wrote:
>> On Mon, Mar 17, 2025 at 9:38 AM Eric Rescorla <[email protected]
>> <mailto:[email protected]>> 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 -- [email protected]
To unsubscribe send an email to [email protected]
