TLS Client Authentication via DANE TLSA records

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction and Motivation

The TLS [RFC8446] and DTLS [RFC9147] protocols optionally support the authentication of clients using X.509 certificates [RFC5280] or raw public keys [RFC7250]. TLS applications that perform DANE [RFC6698] [RFC7671] authentication of servers using TLSA records may also desire to authenticate clients using the same mechanism, especially if the client identity is in the form of or can be represented by a DNS domain name. Some design patterns from the Internet of Things (IoT) plan to make use of this form of authentication, where large networks of physical objects identified by DNS names may authenticate themselves using TLS to centralized device management and control platforms. Other potential applications include authenticating the client side of SMTP transport security.¶

In this document, the term TLS is used generically to describe both the TLS and DTLS (Datagram Transport Layer Security) protocols. The protocol changes described can also be used with QUIC, since QUIC re-uses the TLS handshake.¶

This specification requires TLS 1.3 [RFC8446] or DTLS 1.3 [RFC9147] (or later versions). It relies on extensions carried within the CertificateRequest and Certificate handshake messages, and such per-certificate extensions are not available in earlier versions of the protocols, whose Certificate message carries no extension fields.¶

2. Associating Client Identities in DNS TLSA Records

Different applications may have quite different conventions for naming clients via domain names. This document thus does not prescribe a single format, but mentions a few that may have wide applicability.¶

The name that the client conveys to the server (in the TLS DANE Client Identity extension, see Section 7) is the complete owner name of the client's TLSA record, that is, the exact DNS name the server queries. Unlike server-side DANE [RFC6698], where the verifier derives the TLSA owner name from transport coordinates (the _port._proto prefix), client naming conventions are application-specific; this document describes several below and does not prescribe one. Because the TLS layer is general-purpose and has no knowledge of these conventions, the client conveys the full owner name and the server performs no construction of its own.¶

[_service].[client-domain-name]

[devicename]._device.[org-domain-name]

[client-domain-name]

4. Authentication Model

The authentication model assumed in this document is the following:¶

The client is assigned an identity corresponding to a DNS domain name.¶

The client has a private and public key pair. Where client certificates are being used, the client also has a certificate binding the name to its public key. The certificate or public key has a corresponding TLSA record published in the DNS, which allows it to be authenticated directly via the DNS (using the DANE-TA or DANE-EE certificate usage modes) or via a PKIX public CA system constraint if the client's certificate was issued by a public CA (using the PKIX-TA or PKIX-EE DANE usage modes).¶

5. Client Identifiers in X.509 Certificates

The client conveys its DNS name to the server using the TLS DANE Client Identity extension (see Section 7).¶

With the DANE-EE(3) certificate usage, the presented certificate or public key is matched directly against the TLSA record, so the client's name need not be present in the certificate at all.¶

With the DANE-TA(2), PKIX-TA(0), and PKIX-EE(1) certificate usages, authentication additionally requires the presented certificate to be matched to a reference identity, as specified in [RFC7671]. In these cases the client's name, as conveyed in the TLS DANE Client Identity extension, MUST be present as a dNSName entry in the certificate's Subject Alternative Name extension, and the server MUST verify that it matches; if it does not, the server MUST abort the connection with a handshake_failure alert.¶

The choice of naming convention (Section 2) interacts with the certificate usage mode; see Section 10 for guidance.¶

6. Signaling the Client's DANE Identity in TLS

The client MUST explicitly signal that it has a DANE identity. The most important reason is that the server needs an explicit indication from the client that it has a DANE record, so as to avoid unnecessary DNS queries in-band with the TLS handshake.¶

The DANE Client Identity TLS extension is used for this purpose. A conforming client always conveys its DANE client identity (i.e., domain name) in this extension (see Section 7), so the server never needs to derive it from the certificate. This is particularly important when using TLS raw public key authentication, where there is no certificate from which an identity could be extracted, and when a client certificate contains multiple identities, only a specific one of which has a DANE record.¶

The format of this extension and the detailed client and server behavior are specified in Section 7.¶

7. TLS DANE Client Identity Extension

The DANE Client Identity extension type, "dane_clientid", will have a value assigned and registered in the IANA "TLS ExtensionType Values" registry. Its extension_data field always has the following format:¶

opaque ClientName<0..2^8-1>;

The ClientName field contains the full owner name of the client's TLSA record in textual presentation format, as described in RFC 1035 [RFC1035], omitting the trailing dot. This is the exact DNS name the server queries; the server performs no further construction of it (see Section 2). The lower bound length value of 0 octets indicates that no client name is present (this form is used by the TLS server, in its CertificateRequest message, to advertise that it supports the DANE client authentication protocol).¶

A DNS name is a sequence of octets rather than a Unicode string. Where the client's identity includes internationalized labels, those labels MUST be expressed in their A-label (ASCII-Compatible Encoding) form [RFC5890], which is the form present in the DNS and, per Section 7.2 of [RFC5280], the form required in a certificate's dNSName. U-labels (native Unicode) MUST NOT be used.¶

The wire format of a domain name is limited to 255 octets. In keeping with the practice of most TLS extensions, this extension specifies the use of the textual presentation format of domain names instead. In theory, the presentation format can exceed 255 characters because it allows the expression of any arbitrary octet with the "\DDD" sequence of characters (where DDD is the decimal value). Applications using this extension (and the DANE TLSA Client Authentication protocol more generally) should ensure that client domain names being used do not need to resort to the \DDD syntax by limiting the alphabet suitably, such as only allowing letters, digits, hyphens, and underscores. This ensures that the presentation format client domain name will comfortably fit within the 255 octet limit.¶

A TLS server implementing this specification MUST send the "dane_clientid" extension, with a zero-length ClientName, in its CertificateRequest message, to indicate that it understands the extension and is capable of performing DANE client authentication. The server supplies no name of its own.¶

A TLS client implementing this specification and intending to use DANE client authentication with the TLS server MUST send an extension of type "dane_clientid", with a nonzero-length ClientName populated with the full owner name of the client's corresponding DNS TLSA record (see Section 2), in its Certificate message. Per the TLS protocol, the client is only permitted to send the extension if it sees the corresponding extension in the server's CertificateRequest message.¶

8. Changes to Client and Server Behavior

9. Raw Public Keys

When using raw public keys in TLS [RFC7250], there is no certificate to carry the client's name, so the DANE Client Identity extension (which a conforming client always sends; see Section 7) is the only means by which the client's identity is conveyed. The associated DANE TLSA records employ only certificate usage 3 (DANE-EE) and a selector value of 1 (SPKI), as described in [RFC7671].¶

10. Operational Considerations

The naming conventions described in Section 2 interact with the DANE certificate usage mode a deployment chooses, because of the way a client's name may need to appear in its certificate.¶

Section 4.2.1.6 of [RFC5280] requires that a dNSName in the Subject Alternative Name extension be in the "preferred name syntax", which permits only letters, digits, and hyphens within a label. Underscore-prefixed labels, such as the _service label of the service-specific format or the _device label of the device-identity format (Section 2), therefore cannot appear in a conformant dNSName. This restriction applies to any dNSName, independent of the DANE certificate usage mode.¶

With the DANE-EE(3) usage the client's name need not appear in the certificate (Section 5), and with raw public keys there is no certificate at all (Section 9). Deployments using these can use any of the naming formats in Section 2, including those with underscore-prefixed labels, since the name is conveyed only in the TLS DANE Client Identity extension and matched directly against the TLSA record.¶

With the DANE-TA(2), PKIX-TA(0), and PKIX-EE(1) usages the client's name must appear as a dNSName in the certificate and be matched against it (Section 5), and must therefore be in the preferred name syntax.¶

Whether an underscore-bearing name can be used in these latter cases depends in practice on which certification authority issues the client certificate. The preferred name syntax restriction is not enforced by many TLS and X.509 toolkits, which will create, encode, and verify certificates containing underscore-prefixed dNSNames. An organization operating its own certification authority can therefore issue such certificates for use with the DANE-TA usage, as in the wildcard example of Section 3.2. Commercial certification authorities, however, enforce the restriction and will not issue certificates containing underscore-prefixed dNSNames; deployments relying on them, typically with the PKIX-TA and PKIX-EE usages, cannot use the underscore-bearing formats and should adopt a naming convention that avoids such labels, for example the freeform identity of Section 2.3.¶

It is expected that most deployments of this protocol will use the DANE certificate usages (DANE-EE(3) or DANE-TA(2)), often with an organization-managed CA. As described above, the naming conventions of Section 2, including the underscore-bearing formats, work in practice with these usages. The considerations concerning the preferred name syntax apply primarily to the comparatively less common deployments that rely on the PKIX-TA and PKIX-EE usages with certificates from a commercial certification authority.¶

11. Acknowledgements

For detailed reviews and helpful comments, the authors would like to thank Wes Hardaker, Joey Salazar, Eric Rescorla, Paul Wouters, Ash Wilson, Robert Moskowitz, Bill Woodcock, Olle Johansson, Michael Richardson, Sandoche Balakrichenan, Rick van Rein, Mike Ounsworth, Deb Cooley, Rich Salz, and other members of the IETF DANCE and TLS working groups.¶

12. Security Considerations

This document updates RFC 6698 and RFC 7671 by defining a new way of using DANE for TLS client authentication. Placing client identities in the DNS may pose privacy issues for certain applications, depending on the nature of the clients, the structure and content of the client names, and the mechanisms by which they are queried. In particular, client names that correspond to human persons may pose a graver privacy risk than machine identities. Applications employing this protocol should carefully assess those potential issues, as described below.¶

A design goal of TLS 1.3 is that the client identity is encrypted in the Certificate message, and thus protected from disclosure on the wire. DANE client authentication however relies on the peer (the TLS server in this case) subsequently looking up the client's DANE record in the DNS. Although protocol specifications and implementations to encrypt DNS transport exist, they are very far from ubiquitously deployed. Deployers of DANCE client authentication should thus evaluate the risks of the client name being leaked in this manner by the server, until encrypted DNS transport becomes the norm. A possible way to avoid the TLS server looking up the client's DANE record in the DNS is described in Appendix A, but it has a number of significant challenges.¶

The service specific client identity form lends itself to a structure that might make it easy for the same client to have multiple identities corresponding to different applications using the same public key (e.g., by using wildcards and DANE-EE mode), which could make this protocol susceptible to cross-protocol attacks where traffic is redirected from one service to another. Deployers of this protocol should avoid this by not sharing per client credentials across distinct applications.¶

Because this mechanism cannot operate over TLS 1.2 or earlier (see Section 1), a server that requires DANE client authentication MUST NOT negotiate a protocol version below TLS 1.3 (or DTLS 1.3) for connections where such authentication is mandatory; otherwise the client would be unable to convey its DANE identity and authentication could be silently bypassed.¶

This specification uses a single, generic TLS alert (handshake_failure) for the various client authentication failure conditions it describes, to avoid leaking unnecessary information to potential adversaries.¶

13. IANA Considerations

IANA is requested to create the following entry in the "TLS ExtensionType Values" registry:¶

Extension Name "dane_clientid" with value TBD, "TLS 1.3" column values set to "CR, CT", "DTLS-Only" column set to "N", and "Recommended" column set to "N".¶

The 'N' designation in the "Recommended" column is because this extension has very specific use cases.¶

Appendix A. Possible Future Work

One possible way to address the TLS server-side client identity leak is to suppress the need for the TLS server to lookup the client's DANE record, and instead to have the client supply it. The client could query its own DANE record and the corresponding full DNSSEC authentication chain, and assemble this in a new Certificate Extension that is sent to the TLS server within the handshake. The TLS server would then authenticate this full chain. A specification to do this in the other direction (from the server to the client) already exists: "TLS DNSSEC Chain Extension" [RFC9102]. However, there are several challenges when considering such an approach from the client end. It is quite a heavyweight operation that some constrained clients may have challenges with (for example LoRaWAN clients). In order to construct the DANE authentication chain, the client would need to perform DNS queries which would still leak its identity to the local network environment without encrypted DNS. Lastly, there may be client-side network impediments to making this work, e.g., middleboxes that prevent DNSSEC-enabled queries from succeeding - one of the original motivations for RFC 9102 in the first place. Nevertheless, if appetite to implement this mechanism exists, a future version of this specification could define the details.¶

Authors' Addresses