Internet Engineering Task Force S. Huque Internet-Draft Salesforce Intended status: Standards Track V. Dukhovni Expires: 6 May 2027 OpenSSL Corporation 2 November 2026 TLS Client Authentication via DANE TLSA records draft-ietf-dance-client-auth-16 Abstract The DANE TLSA protocol describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document describes how to use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. In addition, it defines a new TLS extension, DANE Client Identity, to convey the client's domain name identity to the server. 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 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Huque & Dukhovni Expires 6 May 2027 [Page 1] Internet-Draft TLSA client authentication November 2026 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 . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Associating Client Identities in DNS TLSA Records . . . . . . 3 2.1. Format 1: Service Specific Client Identity . . . . . . . 4 2.2. Format 2: IoT Device Identity . . . . . . . . . . . . . . 4 2.3. Format 3: Freeform Client Identity . . . . . . . . . . . 5 3. Example TLSA Records for Clients . . . . . . . . . . . . . . 5 3.1. Format 1: Service Specific Client Identity . . . . . . . 5 3.2. Format 2: IoT Device Identity . . . . . . . . . . . . . . 6 3.3. Format 3: Freeform Client Identity . . . . . . . . . . . 6 4. Authentication Model . . . . . . . . . . . . . . . . . . . . 6 5. Client Identifiers in X.509 Certificates . . . . . . . . . . 7 6. Signaling the Client's DANE Identity in TLS . . . . . . . . . 7 7. TLS DANE Client Identity Extension . . . . . . . . . . . . . 8 8. Changes to Client and Server Behavior . . . . . . . . . . . . 8 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 9 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 9 9. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . . . 11 10. Operational Considerations . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 13.1. TLS ExtensionType Value . . . . . . . . . . . . . . . . 15 13.2. Underscored and Globally Scoped DNS Node Names . . . . . 15 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction and Motivation The TLS [RFC9846] 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 Huque & Dukhovni Expires 6 May 2027 [Page 2] Internet-Draft TLSA client authentication November 2026 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 [RFC9001]. This specification requires TLS 1.3 [RFC9846] or DTLS 1.3 [RFC9147] (or later versions). It relies on extensions carried within the encrypted CertificateRequest and Certificate handshake messages. Earlier versions of the protocols do not support such extensions, since their Certificate message carries no extension fields, and they send these messages unencrypted. Carrying the client's DANE identity inside encrypted handshake messages protects it from disclosure on the network path; however, see Section 12 regarding its possible exposure through DNS queries. This protocol is intended for deployments in which disclosure of the client's name to DNS resolvers and authoritative servers is acceptable, such as devices and services identified by machine names. It is generally unsuitable where the client's identity must be kept confidential, for example where client names identify individual people, unless the mitigations described in Section 12 are applied. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 Huque & Dukhovni Expires 6 May 2027 [Page 3] Internet-Draft TLSA client authentication November 2026 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. Formats 1 and 2 below use underscore-prefixed labels. Their global underscored node names [RFC8552], "_client" and "_device" respectively, are registered for the TLSA RR type (see Section 13). An application that defines its own naming convention employing underscore-prefixed labels needs to register the corresponding global underscored node name, as required by [RFC8552]. 2.1. Format 1: Service Specific Client Identity In this format, the owner name of the client TLSA record has the following structure: [_service]._client.[client-domain-name] The first label identifies the application service name. It is followed by the fixed label "_client", and the remaining labels form the client domain name. Encoding the application service name into the owner name allows the same client domain name to have different authentication credentials for different application services. There is no need to encode the transport label - the same name form is usable with both TLS and DTLS. The "_client" label is the global underscored node name of this format [RFC8552], and the _service label is scoped beneath it. The _service label is expected to be a service name registered in the IANA Service Name Registry [SRVREG] prefixed with an underscore, but could also be a custom string defined by an application; such a string should be chosen so as not to coincide with a registered service name. Labels beneath "_client" are not entered in the "Underscored and Globally Scoped DNS Node Names" registry. The RDATA or data field portion of the TLSA record is formed exactly as specified in [RFC6698] and [RFC7671], and carries the same meaning. 2.2. Format 2: IoT Device Identity The Device Identity form of the TLSA record has the following structure: Huque & Dukhovni Expires 6 May 2027 [Page 4] Internet-Draft TLSA client authentication November 2026 [devicename]._device.[org-domain-name] The "_device" label interposed between the client device name labels and the organization domain labels allows management of all client identities to be delegated to a subzone or to another party. The "_device" label is the global underscored node name of this format [RFC8552]. 2.3. Format 3: Freeform Client Identity In this format, the owner name of the client TLSA record is an ordinary DNS domain name, with no service label or other structural label interposed: [client-domain-name] This form imposes no structure beyond a domain name that identifies the client. Because it need not contain any underscore-prefixed labels, it can be represented directly in the dNSName component of the Subject Alternative Name extension of an X.509 certificate. It is therefore the most suitable form for deployments whose client certificates are issued by a public Certification Authority, or that otherwise rely on the certificate to carry the client's name, since public CAs and the dNSName type do not generally permit underscore- prefixed labels. 3. Example TLSA Records for Clients The following examples are provided in the textual presentation format of the DNS TLSA record. 3.1. Format 1: Service Specific Client Identity An example TLSA record for the client "device1.example.com." and the application service "smtp". This record specifies the SHA-256 hash of the subject public key component of the end-entity certificate corresponding to the client. The certificate usage for this record is 3 (DANE-EE) and thus is validated in accordance with Section 5.1 of [RFC7671]. _smtp._client.device1.example.com. IN TLSA ( 3 1 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971 ) Huque & Dukhovni Expires 6 May 2027 [Page 5] Internet-Draft TLSA client authentication November 2026 3.2. Format 2: IoT Device Identity An example TLSA record for the device named "sensor7" managed by the organization "example.com". This record specifies the SHA-512 hash of the subject public key component of an EE certificate corresponding to the client. sensor7._device.example.com. IN TLSA ( 3 1 2 0f8b48ff5fd94117f21b6550aaee89c8 d8adbc3f433c8e587a85a14e54667b25 f4dcd8c4ae6162121ea9166984831b57 b408534451fd1b9702f8de0532ecd03c ) The example below shows a wildcard TLSA record mapped to a TLSA record with a DANE-TA usage mode. This allows all client identifiers matching the wildcard to be authenticated by client certificates issued by an organization-managed Certification Authority. This example presumes an organization-managed CA willing to issue the underscore-prefixed device name; see Section 10. *._device.example.com. IN TLSA ( 2 0 1 20efa254ecd5b646e701211095bc3fe4 423e21941b0b29efb21da57ec944a9b5 ) 3.3. Format 3: Freeform Client Identity An example TLSA record for the client "device73.example.com", whose certificate is issued by a public Certification Authority. This record specifies certificate usage 1 (PKIX-EE) and the SHA-256 hash of the subject public key component of the end-entity certificate corresponding to the client. device73.example.com. IN TLSA ( 1 1 1 d13576c4333389c6489df3566f29a449 b413f3225ff87a3fb028535596a7af08 ) 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- Huque & Dukhovni Expires 6 May 2027 [Page 6] Internet-Draft TLSA client authentication November 2026 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. Huque & Dukhovni Expires 6 May 2027 [Page 7] Internet-Draft TLSA client authentication November 2026 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 the common display format described in Section 2 of [RFC9499], without 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). Each label of the name MUST consist only of ASCII letters, digits, hyphens, and underscores, so that the name never requires the escape sequences of the [RFC1035] presentation format. The name MUST be a valid domain name, and is therefore at most 255 octets in wire format [RFC1035]. Given the character restriction above, it is then at most 253 octets long in this form, and so always fits within the ClientName field. Internationalized labels MUST be expressed in their A-label form [RFC5890], which is the form present in the DNS and, per Section 7.2 of [RFC5280] as updated by [RFC9549], the form required in a certificate's dNSName; U-labels MUST NOT be used. 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 Section 4.5.1 of [RFC9846], the client may only send the extension if the server's CertificateRequest message included it; a server receiving it otherwise aborts the handshake with an "unsupported_extension" alert (Section 4.3 of [RFC9846]). 8. Changes to Client and Server Behavior Huque & Dukhovni Expires 6 May 2027 [Page 8] Internet-Draft TLSA client authentication November 2026 8.1. Client Behavior DANE client authentication requires that a DNSSEC [RFC9364] signed TLSA record, corresponding to the client's X.509 certificate or public key, be published at the owner name the client conveys in its ClientName (see Section 2). A client can only use this protocol with a server that supports it and advertises that support by including a DANE Client Identity extension (with a zero-length ClientName) in its CertificateRequest message. When the client receives such a CertificateRequest, and intends to authenticate using DANE, it presents its certificate or public key and MUST send the DANE Client Identity extension in its Certificate message, carrying a nonzero-length ClientName populated with the full owner name of its TLSA record, as specified in Section 7. 8.2. Server Behavior 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 (see Section 1). A TLS Server implementing this specification performs the following steps: 1. Request a client certificate in the TLS handshake's CertificateRequest message, that includes a DANE Client Identity extension with a zero-length ClientName. 2. Receive the client's Certificate message, together with any DANE Client Identity extension it carries. 3. If the client sent a nonzero-length ClientName in the DANE Client Identity extension of its Certificate message, extract the client's domain name from it. If the client sent the extension with a zero-length ClientName, this is a protocol violation (a conforming client sends a nonzero-length name, per Section 7); the server MUST abort the connection with a handshake_failure alert. If the client did not send the extension at all, it has not requested DANE client authentication, and this specification does not apply to the connection. A server that supports DANE client authentication alongside other modes (for example, traditional TLS client authentication, or accepting unauthenticated clients) then handles the connection according to its general client-authentication policy; a server that requires DANE client authentication MUST abort the connection with a handshake_failure alert. Huque & Dukhovni Expires 6 May 2027 [Page 9] Internet-Draft TLSA client authentication November 2026 4. If the server applies name-based authorization rules (see below), it SHOULD first check the client's domain name against them, and reject a name that is not permitted without performing the lookup. Otherwise, look up the TLSA record set in the DNS, using the client's domain name obtained in the previous step directly as the DNS query name. The response MUST be cryptographically validated using DNSSEC. The server could perform DNSSEC validation itself, authenticating the full chain back to a configured trust anchor (normally the DNS root). Alternatively, it could also be configured to trust responses obtained via a validating resolver to which it has a secure connection, by requiring the Authenticated Data (AD) bit to be set in the responses. If any result other than a DNSSEC validated TLSA record set is returned, the server MUST either abort the connection with a handshake_failure TLS alert, or, if server policy allows, treat the client as unauthenticated. Such other results include DNSSEC validation failures, unauthenticated answers (because of an unsigned DNS zone or insecure delegation along the path to the TLSA owner name), NXDOMAIN, or NODATA responses. 5. Extract the RDATA of the TLSA records and match them to the presented client certificate according to the rules specified in the DANE TLS protocol [RFC6698] [RFC7671]. If successfully matched, the client is authenticated and the TLS session proceeds. If unsuccessful, the server MUST either abort the connection with a handshake_failure TLS alert, or treat the client as unauthenticated, if TLS server policy allows. 6. If there are multiple records in the TLSA record set, then the client is authenticated as long as at least one of the TLSA records matches, subject to [RFC7671] digest agility, which SHOULD be implemented. When the client's name is expected to appear in the certificate, and the certificate contains multiple dNSName identities, the ClientName sent in the TLS DANE Client Identity extension unambiguously indicates which one is the client's name. If the name in the TLS DANE Client Identity extension does not match one of the dNSNames in the certificate, then the server MUST abort the connection with a handshake_failure TLS alert. The client identity authenticated by this protocol is the name carried in the ClientName field. The TLS implementation needs to make this name available to the application. Other names in the client's certificate are not authenticated by this protocol; in particular, with the DANE-EE usage, names in the certificate are not checked at all (see Section 5.1 of [RFC7671]). Huque & Dukhovni Expires 6 May 2027 [Page 10] Internet-Draft TLSA client authentication November 2026 Servers may have their own allowlisting and authorization rules for which client names they accept. For example a TLS server may be configured to only allow TLS sessions from clients with client names within a specific domain or set of domains. If such rules are not met, the TLS server MUST either abort the connection with a handshake_failure TLS alert, or treat the client as unauthenticated, if TLS server policy allows. Because the ClientName is supplied by a not yet authenticated peer, the lookup in step 4 can be directed at any name, including names in zones whose authoritative servers respond slowly or not at all. This matters most for servers that accept arbitrary client names, where no allowlist applies. Servers should bound the time spent on the lookup, treating a timeout as a failure under step 4, and should rely on caching of TLSA responses, per their TTLs, to avoid repeated queries. 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 Section 5.1 of [RFC7671]. The client's public key is bound to its name solely by these DNSSEC- validated TLSA records: the server matches the SubjectPublicKeyInfo in the client's Certificate message against them, either in full (matching type 0) or by its SHA-256 or SHA-512 digest (matching types 1 and 2), and the client's CertificateVerify message proves possession of the corresponding private key. 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 and _client labels 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. Huque & Dukhovni Expires 6 May 2027 [Page 11] Internet-Draft TLSA client authentication November 2026 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. Huque & Dukhovni Expires 6 May 2027 [Page 12] Internet-Draft TLSA client authentication November 2026 The TLSA publisher requirements and operational considerations in Sections 8 and 13 of [RFC7671] apply to client TLSA records, with the roles of client and server reversed. In particular, when a client's key or certificate is rotated, TLSA records matching the new credential should be published, and the TTL of the existing records allowed to elapse, before the client starts using it. With the DANE- EE(3) usage, certificate expiration is ignored (Section 5.1 of [RFC7671]), so removing or replacing the client's TLSA records is the means of revoking its credential. Servers may continue to accept a revoked credential until previously cached records expire, and an attacker able to replay them can extend this until their DNSSEC signatures expire. The TTL and signature validity period of client TLSA records should be chosen with this in mind. Client authentication depends on the server obtaining DNSSEC- validated responses, and so on the availability of its validating resolver and of correctly signed client zones. An outage of either causes all affected clients to fail authentication, or, where server policy allows, to be treated as unauthenticated (Section 8.2). Operators should provision redundant validating resolvers and monitor the DNSSEC signatures of client zones. Although the server sends only a generic alert on authentication failure (Section 12), it should log the specific cause (e.g., DNSSEC validation failure, an insecure response, NXDOMAIN or NODATA, lookup timeout, TLSA mismatch, or rejection by local policy) along with the ClientName, so that operators can diagnose failures. Such logs contain client identities and should be protected accordingly. 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, Kaveh Ranjbar, Matt Brown, and other members of the IETF DANCE and TLS working groups. 12. Security Considerations This document extends the use of DANE TLSA records [RFC6698] [RFC7671] to 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 Huque & Dukhovni Expires 6 May 2027 [Page 13] Internet-Draft TLSA client authentication November 2026 below. In TLS 1.3, the client identity is encrypted in the Certificate message, and thus normally protected from disclosure on the wire. DANE authentication however relies on the peer (the TLS server in this case) subsequently looking up the client's DANE record in the DNS. Unless encrypted DNS transport is used (e.g., DNS over TLS [RFC7858], DNS over HTTPS [RFC8484], or DNS over QUIC [RFC9250]), this can expose the client name in the clear, and thus deployers of DANE client authentication should carefully evaluate any resulting privacy risks. To mitigate this risk, deployments should ensure encrypted DNS is used to the extent possible. This could involve turning on encrypted DNS between the TLS server and its local resolver, enabling it at the authoritative servers hosting the DANE client records, and using data minimization techniques like query name minimization [RFC9156] to avoid exposing the most specific parts of the client DNS names to layers that (largely) have no encrypted DNS today (e.g., the DNS root, and many DNS Top Level Domains). A possible way to avoid the TLS server looking up the client's DANE record in the DNS, is to have the client instead perform the DNS lookups for its own DANE record set, and assemble it and the associated full DNSSEC authentication chain in a new Certificate Extension that is sent to the TLS server. 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 with this approach: 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. 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. Huque & Dukhovni Expires 6 May 2027 [Page 14] Internet-Draft TLSA client authentication November 2026 This mechanism cannot operate over TLS 1.2 or earlier (see Section 1). A server that negotiated an earlier version would not receive the client's DANE identity, and authentication could be silently bypassed. Section 8.2 therefore requires TLS 1.3 or DTLS 1.3 where DANE client authentication is mandatory. 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 13.1. TLS ExtensionType Value 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", "Recommended" column set to "N", and "Comment" column set to "For TLS 1.3 or later". The 'N' designation in the "Recommended" column is because this extension has very specific use cases. 13.2. Underscored and Globally Scoped DNS Node Names IANA is requested to add the following entries to the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]: +=========+============+============================+ | RR Type | _NODE NAME | Reference | +=========+============+============================+ | TLSA | _client | This document, Section 2.1 | +---------+------------+----------------------------+ | TLSA | _device | This document, Section 2.2 | +---------+------------+----------------------------+ Table 1 14. References 14.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . Huque & Dukhovni Expires 6 May 2027 [Page 15] Internet-Draft TLSA client authentication November 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, . [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, . Huque & Dukhovni Expires 6 May 2027 [Page 16] Internet-Draft TLSA client authentication November 2026 [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . [RFC9549] Housley, R., "Internationalization Updates to RFC 5280", RFC 9549, DOI 10.17487/RFC9549, March 2024, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, . 14.2. Informative References [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . [RFC9102] Dukhovni, V., Huque, S., Toorop, W., Wouters, P., and M. Shore, "TLS DNSSEC Chain Extension", RFC 9102, DOI 10.17487/RFC9102, August 2021, . [RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156, DOI 10.17487/RFC9156, November 2021, . [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . Huque & Dukhovni Expires 6 May 2027 [Page 17] Internet-Draft TLSA client authentication November 2026 [SRVREG] IANA, "Service Name and Transport Protocol Port Number Registry", . Authors' Addresses Shumon Huque Salesforce Email: shuque@gmail.com Viktor Dukhovni OpenSSL Corporation Email: ietf-dane@dukhovni.org Huque & Dukhovni Expires 6 May 2027 [Page 18]