Subject: Re: [Dance] DANE client authentication for HTTPS

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 1 Feb 2022 10:11:39 +0100

> On 31 Jan 2022, at 22:02, Ash Wilson <ash.wilson=[email-masked]> wrote:
> 
> 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 <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.
That’s a good point to add as good practise to our documents.

>   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.
What is the content of your client cert here? Could it have a field indicating the client identifier? Or would it not help. *thinking*
> 
> 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.

Cool! I will take a more detailed look, but I do appreciate code examples to work from.

Thank you!

/O

---

From: Ash Wilson <[email-masked]>
Date: Tue, 1 Feb 2022 09:15:18 -0800

On Tue, Feb 1, 2022 at 1:11 AM Olle E. Johansson <[email-masked]> wrote:

>
>
> On 31 Jan 2022, at 22:02, Ash Wilson <
> ash.wilson=[email-masked]> wrote:
>
> 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 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.
>
>   The application's client authentication settings (authn/authz) are
> managed in the web application, not in the load balancer.
> 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.
>
> What is the content of your client cert here? Could it have a field
> indicating the client identifier? Or would it not help. *thinking*
>

The client certificate may contain a useful identifier in the dNSName, but
I don't know that there's a sufficiently simple way to pick a specific
identifier from what may be a plurality in the SAN extension of the
certificate. If we specify the client identifier independent of the
certificate, then this could work with a raw public key as well.

>
> 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.
>
>
> --
> Dance mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dance
>

-- 

*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.