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.
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.
> 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? Probably the client knows best
which identity it presents to a particular server (and whether a default
applies generally, ...). 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.
> 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.
> 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.
--
Viktor.
_______________________________________________
dane mailing list -- [email protected]
To unsubscribe send an email to [email protected]
