On Tue, May 20, 2025 at 2:56 PM Viktor Dukhovni <[email protected]> wrote:
> On Tue, May 20, 2025 at 01:32:08PM -0400, Phillip Hallam-Baker wrote: > > > I remain skeptical of DANE on the server side. Seems to me that ACME and > > LetsEncrypt have closed the door there. However, I suddenly realised > there > > is an opportunity on the client side. > > > > I could do this with a TXT record and might still go that way. But here > is > > the concept. > > The good news is that DANE should be easier to deploy in this context, > because servers generally don't face the same last-mile issues that > impede DANE deployment on edge-system clients. > Totally, can even mint a new TLSA record for client side if needed. The normal constraints don't apply here. The scheme depends on either the user only having one device or there being some sort of CA like thing operating. And anyone doing that can manage a DNS record outside the magic 7 Aftet getting DANE done for SMTP servers, I ran out of cycles to do the > same for the client side, so > > https://datatracker.ietf.org/doc/html/draft-huque-dane-client-cert-08 > > has been gestating for many years now. Perhaps you could help to see it > through to completion, and I may then find some cycles to do likewise. > I am seeing that as being fortuitous because the thing that makes this interesting is Blue Sky's 35 million users of DNS Handles. That gives us the deployment opportunity. It also gives me a bit more leverage when saying we need to yeet the PLC registry used to map DIDs to OAUTH servers in the Blue Sky ATprotocol scheme. If the long term plan is to yeet the OAUTH server out of the picture entirely, that makes sense. TLS failed client side because TLS is predicated on a DNS address (no really, it just is) and users didn't have them, not till DNS Handles. > So what if my DNS Handle provider is running a CA just for me and my > > browsers. The root cert for the CA is bound to my DNS Handle via a TXT or > > TLSA record. > > > > Each time I config a new browser, I go through some 2FA mechanism with > the > > CA and it plops a cert into my browser. > > > > When I visit a Web site, during the initial TLS handshake, the server > says > > it supports 'Transparent Client Side Authentication' (TCSA). > > > It may be useful for the client to signal support for in its TLS client > hello. The key question is who decides which of your identities is the > right one for the server in question? I gave a bit more on that in my email to the OAUTH group. My vision for privacy and identity is a bit different to the normal 'keep everything separate'. I expect to have multiple personas and for the browser to remember which persona I have nominated for a particular site. So lets assume I have my two personas, @phill.hallambaker.com and @ salvador.cryptomesh.com when I am going to dalek meetups (101st Legion for Who fans). I don't want my professional contacts knowing I am doing the dalek thing, but I am happy for people in the dalek world to know it is me. When I visit a site, it won't give any authentication unless I tell it to. First time I am asked to log in, I am going to pick the persona to log in under. Linked in is obviously my professional, Project Dalek is my dalek persona. We can kick back across HTTP to trigger the enrollment data flow. Don't need to do it all in TLS. The browser can keep track of things using a Bloom Filter to make a first cut. If there is a match, it looks up the site and picks the persona and cert for that site. And this is all automatic. > Probably the client knows best > which identity it presents to a particular server (and whether a default > applies generally, ...). Default is not to authenticate at all. > If not impeded by last-mile problems, along > with its certificate or raw public key, the client might include the > relevant DNSSEC proof as a certificate extension, otherwise, it might > provide just the DNS name leaving it to the server to perform the > lookup. > We can dial the validation criteria up or down as needed. > > Browser does TLS client side auth presenting the cert it was issued. > > With TLSA 3 1 X records, this could be just a raw public key. > That isn't going to work because users have multiple devices. It isn't worth building out anything for the single device use case. Each device should have its own key. Much easier to make that work correctly... I did also consider the LetsEncrypt/ACME route but what does that buy us? The relying party in this case has just as much opportunity to perform an unspoofed DNS lookup as a CA. Not sure what WebPKI is buying us. > > I am now authenticated against @phill.hallambaker.com. > > Yes, the general idea of the languishing draft. > > > This approach does need some changes to the browser but they are > > modest changes. I might even be able to implement them in my own > > browser PHB at some point. All it takes is an API that exposes the > > necessary hooks. > > I may be able to do add the relevant support in OpenSSL, DANE for server > certs is already implemented, the main obstacle is that there isn't a > ubiquitous API for authenticating client-provided DNSSEC chains. So > validation of the client chain or fetching it on demand would be up to > the application via its preferred DNS library, and not directly > performed by OpenSSL. Once the server provides the relevant TLSA > records to the library, the certificate verification can proceed using > existing DANE support which is essentially direction agnostic. > Perhaps a side meeting in MADRID, maybe some of the browser folk could provide input... There are multiple issues here. 1) Client to server signalling. 2) Server to client signalling. 3) Issue of the certificate signing certificates. 4) Issue of the end entity certificates. 5) Signalling enrollment for TCSA
_______________________________________________ dane mailing list -- [email protected] To unsubscribe send an email to [email protected]
