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. > > * 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 > >> >> >> >> >> On Tue, May 20, 2025 at 7:45 PM Phillip Hallam-Baker < >> ph...@hallambaker.com> wrote: >> >>> I have floated parts of this scheme in OAUTH and DANE. >>> >>> As we all know, TLS does Client auth in theory but the implementations >>> are unusable for two reasons: >>> >>> 1) Issue of client side certs is a pain >>> 2) The user interface asking the user to select a certificate. >>> >>> Both problems could potentially be addressed by the emerging DNS handles >>> infrastructure. At present, the authentication is OAUTH2 based. But TLS >>> Client Authentication under a certificate validated under the DNS handle >>> would be cleaner. >>> >>> So, I am looking for people interested in a side meeting in Madrid. >>> >>> Here is my current sketch: >>> >>> User gets handle from DNS Handle provider who (usually) also runs an >>> OAUTH2 service under the ATprotocol profile and a private CA for the user. >>> >>> The root of the private CA is bound to the DNS zone by a TXT or TLSA >>> record. >>> >>> Each device the user wants to use with their DNS handle gets issued its >>> own client cert. >>> >>> Users can have multiple personas and the browser selects the certificate >>> the user has assigned to the site asking for authentication. >>> >>> >>> Net is that the user gets to authenticate to any site (supporting T2CA) >>> under the DNS Handle and persona they have selected for their site without >>> any additional hassle. >>> >>> >>> _______________________________________________ >>> 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
