On Thu, May 22, 2025 at 11:50 AM Eric Rescorla <[email protected]> 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 [email protected]. 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. [Also in this model, the handle is merely a discovery mechanism mapping to a DID that is a permanent identifier and a fingerprint of a root of trust so you can change handles which is what I did when I traded @hallam.bsky.social for @phill.hallambaker.com. But let's leave that aside for now.] I agree that there isn't really much value in having a CA issued cert if they are only going to do domain validation. But given that we will only be putting fingerprints of keys in the DNS and given that TLS is really predicated on PKIX, I think it easiest to use certs as a means of transporting the public key. >From a technical perspective, I think the bigger picture question is > whether TLS is the right layer for this. As you know, TLS supports > certificate-based client authentication, but that has largely been > deprecated, even for cryptographic authentication, in favor of > application layer solutions like WebAuthn or Passkeys. There are are a > number of reasons for this, including: > Given my experience of trying to use passkeys, I am distinctly unimpressed. And I will remain unimpressed until I can log into GitHub using my passkey from my Windows machine. They have had over ten years to work out how to make the keys work across multiple devices. Without that, they have no solution at all. And they can't call it an open system until there is seamless operation across Windows, Apple and Linux. Even if they could fix all that, I can't see passkeys as ever being useful for more than authenticating the user to their IdP because the amount of fuss involved in setting up a passkey is ridiculous. * 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. I'm aware that there are mechanisms to make this work inside of TLS > but they require close coordination between the application, HTTP, > and TLS, whereas solutions like WebAuthn do not. > They do at present and I believe that is because there is too much flexibility in the specification so that the user is effectively being asked to pick the authentication flavor.Standards are about making choices. The Client Auth spec leaves far too much unspecified. All the user should need to do is tell the browser, 'log into this site using my xyz.example.com persona in future'. And then that just happens. There is no user experience, it all just happens transparently. We have to specify a mechanism by which an unauthenticated client gets prompted to become authenticated of course. > From a deployment perspective, we have very wide deployment of OAuth > based authentication and both IdPs and RPs are comfortable with > that. Deploying something like this would require them all to change > as well as a fair amount of work by the browser vendors. Previous > attempts to deploy other signature-based federated ID systems (e.g., > BrowserId/Persona) have foundered due to lack of deployment interest, > so I think an important question to ask here is whether there is real > interest from a critical mass of the relevant parties. > Currently, I can use OAUTH to log into Web sites using my Facebook, Google or Apple accounts. Not only does my IdP get a huge amount of traffic analysis on my activities, they are receiving a vast amount of GDPR exposure which is probably doubleplus ungood for the IdP providers. Using a DNS handle as the account identifier to an OAUTH service is the logical way to give the user control of their 'everywhere account'. The DNS is the naming system for the Internet after all. I am not seeing TLS client auth as a competitor to that scheme, I am looking at it as a seamless upgrade for 2026 or beyond. The idea being that if there are browsers that make use of the multiple persona approach, then client auth becomes a natural additional adjunct. The area where this will matter is solving the problem of how I change the temperature on my IoT thermostat from my laptop connected to my local network when the Internet connection is down. > -Ekr > > [0] I'm leaving for later the question of whether DNS is the right > approach here, compared to approaches like having the signing key > in /.well-known. > > > > > > > > > > On Tue, May 20, 2025 at 7:45 PM Phillip Hallam-Baker < > [email protected]> 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
