On Thu, May 22, 2025 at 10:28 AM Phillip Hallam-Baker <ph...@hallambaker.com> wrote:
> > > On Thu, May 22, 2025 at 1:04 PM Eric Rescorla <e...@rtfm.com> wrote: > >> >> >> On Thu, May 22, 2025 at 9:56 AM Phillip Hallam-Baker < >> ph...@hallambaker.com> wrote: >> >>> >>> >>> On Thu, May 22, 2025 at 11:50 AM Eric Rescorla <e...@rtfm.com> wrote: >>> >>>> A few observations here. >>>> >>>> I generally agree that a signature-based scheme has superior privacy >>>> properties to something like OAuth, though the details really matter >>>> here. For example, if the system requires having a TXT record at the >>>> leaf node (e.g., ekr.<something>.gmail.com) then the end result is >>>> similar because the DNS server will get a query from the relying party >>>> for your specific identity, allowing the server to track you [0] >>>> >>> >>> The idea here is that you have your own personal DNS name that is yours >>> and only you use for authentication. It is a different approach but one >>> that has some surprising effects. >>> >>> A traditional Internet account is a delegation to a service. so >>> e...@example.com. To resolve that name, a client first locates the auth >>> server for rtfm.com and then sends it a query. >>> >>> In the Blue Sky model, your account has its own DNS name and can be >>> queried independently of any account discovery service: @ekr.example.com >>> . >>> >> >> Yes, I understand this, but as a practical matter, people don't have >> their own DNS names, and I don't think it's likely they are going to get >> them. Rather, they are likely to have them subordinated under some >> provider, exactly as they do now, in which case it will be ` >> al...@gmail.com` which maps to `alice.gmail.com`, hence the privacy >> point I am making. >> > > I accept that most people are going to go for a free DNS handle issued by > a handle provider. But a system in which users have the option of exit has > completely different dynamics to one where they are locked in by switching > costs. > Yes, I agree with this. But even in the case where the DNS handle is associated with my own server, that server is then likely hosted by some DNS hosting provider, and so we have to worry about privacy via that provider. > * Allowing the site to control the timing of the authentication >> (e.g., offering you connect unauthenticated and then upgrading). >> * Allowing the site to offer multiple authentication options. >> * Allowing the site to control the look and feel of the interaction. >> > > I don't want the site to be doing any of that. I want there to be a single > consistent authentication experience across everything. Without > consistency, users have no idea what they are doing and the scheme is > vulnerable to social engineering attacks. > >> What matters here is not what you want but rather what the site wants, >> and in my experience they want these properties. >> So, again, I ask: which major players in the current ecosystem are >> interested in this. >> >> -Ekr >> > > The target 'site' in this case is the HTTPS server built into my next IoT > thermostat after the current one is disabled because of malicious > obsolescence. > OK, but there are still vendors who need to do things, so I think my question continues to be relevant. Which device and/or browser vendors are interested? -Ekr
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
