Subject: [Dance] DANE client authentication for HTTPS

From: Ash Wilson <[email-masked]>
Date: Mon, 31 Jan 2022 13:02:43 -0800

Hi DANCErs,

I'm sharing a proof-of-concept implementation of a web application which
uses DANE for client authentication:
https://github.com/ValiMail/traefik_flask_pki_dns

This approach separates DANE client authentication from the TLS handshake,
and represents a pattern which works better for large web applications. The
challenges with large web applications which this PoC seeks to overcome,
center mainly around managing the configuration for TLS client
authentication in a TLS-terminating load balancer, and preventing the TLS
server from being an abuse vector for triggering arbitrary DNS lookups for
not-authorized identities.

The PoC works like this:
  The client has a DANE identity represented in DNS.
  The TLS server is in the Traefik load balancer, and is configured to only
verify that the client possesses the private key corresponding to the
certificate's public key. The load balancer does not perform full PKIX
chain verification.
  The client uses its DANE-represented certificate to authenticate to the
Traefik load balancer. If TLS client authentication is successful, the
client sends an HTTP header containing the DANE DNS name where the TLSA
record can be found, and the load balancer injects a header containing the
verified entity certificate.
  The web application first ensures that the DANE ID is a valid client
identifier for the application, then uses DNS to get the TLSA record for
verifying the presented certificate.

This approach offers the following benefits:
  No DNS lookups performed for identifiers which are not associated with
valid clients.
  The application's client authentication settings (authn/authz) are
managed in the web application, not in the load balancer.
  No changes to the TLS handshake

This pattern may also work well for other protocols which require granular
and/or dynamic management of client identities. HTTP gives us headers to
convey the client identifier with, and other TLS-wrapped protocols offer
similar functionality.

It makes sense for the email ecosystem to bake DANE client authentication
into the TLS handshake, and the intent here is not to interrupt the work of
updating the TLS handshake to perform DANE authentication for clients.
However, DANE client adoption will be easier for RESTful APIs using a
pattern like this, which allows granular control over the DANE portion of
the authentication process to be delegated to the web application itself.

-Ash

-- 

*Ash Wilson * | Technical Director
*e:* [email-masked]

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.