TLS Client Authentication via DANE TLSA records
draft-ietf-dance-client-auth-14

Internet Engineering Task Force                                 S. Huque
Internet-Draft                                                Salesforce
Updates: 6698, 7671 (if approved)                            V. Dukhovni
Intended status: Standards Track                     OpenSSL Corporation
Expires: 15 March 2027                                 11 September 2026

            TLS Client Authentication via DANE TLSA records
                    draft-ietf-dance-client-auth-14

Abstract

   The DANE TLSA protocol describes how to publish Transport Layer
   Security (TLS) server certificates or public keys in the DNS.  This
   document updates RFC 6698 and RFC 7671.  It 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 15 March 2027.

Copyright Notice

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

Huque & Dukhovni          Expires 15 March 2027                 [Page 1]
Internet-Draft         TLSA client authentication         September 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  . . . . . . .   3
     2.2.  Format 2: IoT Device Identity . . . . . . . . . . . . . .   4
     2.3.  Format 3: Freeform Client Identity  . . . . . . . . . . .   4
   3.  Example TLSA Records for Clients  . . . . . . . . . . . . . .   5
     3.1.  Format 1: Service Specific Client Identity  . . . . . . .   5
     3.2.  Format 2: DevID . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Format 3: Freeform Client Identity  . . . . . . . . . . .   6
   4.  Authentication Model  . . . . . . . . . . . . . . . . . . . .   6
   5.  Client Identifiers in X.509 Certificates  . . . . . . . . . .   6
   6.  Signaling the Client's DANE Identity in TLS . . . . . . . . .   7
   7.  TLS DANE Client Identity Extension  . . . . . . . . . . . . .   7
   8.  Changes to Client and Server Behavior . . . . . . . . . . . .   8
     8.1.  Client Behavior . . . . . . . . . . . . . . . . . . . . .   8
     8.2.  Server Behavior . . . . . . . . . . . . . . . . . . . . .   8
   9.  Raw Public Keys . . . . . . . . . . . . . . . . . . . . . . .  10
   10. Operational Considerations  . . . . . . . . . . . . . . . . .  10
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  12
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     14.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

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
   DNS domain name.  Some design patterns from the Internet of Things
   (IoT) plan to make use of this form of authentication, where large

Huque & Dukhovni          Expires 15 March 2027                 [Page 2]
Internet-Draft         TLSA client authentication         September 2026

   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 [RFC9846] 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.

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

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-domain-name]

Huque & Dukhovni          Expires 15 March 2027                 [Page 3]
Internet-Draft         TLSA client authentication         September 2026

   The first label identifies the application service name.  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 _service label could be a custom string for an application, but
   more commonly is expected to be a service name registered in the IANA
   Service Name Registry [SRVREG].

   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:

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

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.

Huque & Dukhovni          Expires 15 March 2027                 [Page 4]
Internet-Draft         TLSA client authentication         September 2026

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 "smtp-client".  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 )

3.2.  Format 2: DevID

   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 )

Huque & Dukhovni          Expires 15 March 2027                 [Page 5]
Internet-Draft         TLSA client authentication         September 2026

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 d2abde240d7cd3ee6b4b28c54df034b9
            7983a1d16e8a410e4561cb106618e971 )

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.

Huque & Dukhovni          Expires 15 March 2027                 [Page 6]
Internet-Draft         TLSA client authentication         September 2026

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

Huque & Dukhovni          Expires 15 March 2027                 [Page 7]
Internet-Draft         TLSA client authentication         September 2026

   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

8.1.  Client Behavior

   A TLS client conforming to this specification MUST have a DNSSEC
   [RFC9364] signed TLSA record published corresponding to its DNS name
   and X.509 certificate or public key.

   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 TLS Server implementing this specification performs the following
   steps:

Huque & Dukhovni          Expires 15 March 2027                 [Page 8]
Internet-Draft         TLSA client authentication         September 2026

   1.  Request a client certificate in the TLS handshake's "Certificate
       Request" 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.

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

Huque & Dukhovni          Expires 15 March 2027                 [Page 9]
Internet-Draft         TLSA client authentication         September 2026

   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.

   Servers may have their own allowlisting and authorization rules for
   which certificates they accept.  For example a TLS server may be
   configured to only allow TLS sessions from clients with certificate
   identities 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.

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

Huque & Dukhovni          Expires 15 March 2027                [Page 10]
Internet-Draft         TLSA client authentication         September 2026

   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.

Huque & Dukhovni          Expires 15 March 2027                [Page 11]
Internet-Draft         TLSA client authentication         September 2026

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.

   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.  Since encrypted DNS transport is not yet widely deployed, this
   can expose the client name in the clear, and thus deployers of DANCE
   client authentication should carefully evaluate any resulting privacy
   risks.  To mitigate this risk, DANCE deployments should ensure
   encrypted DNS is used to the extent possible.  This could involve
   turning on encrypted DNS between the DANCE 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

Huque & Dukhovni          Expires 15 March 2027                [Page 12]
Internet-Draft         TLSA client authentication         September 2026

   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.

14.  References

14.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc5280>.

Huque & Dukhovni          Expires 15 March 2027                [Page 13]
Internet-Draft         TLSA client authentication         September 2026

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [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, <https://www.rfc-editor.org/info/rfc6698>.

   [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, <https://www.rfc-editor.org/info/rfc7250>.

   [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, <https://www.rfc-editor.org/info/rfc7671>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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,
              <https://www.rfc-editor.org/info/rfc9147>.

   [RFC9364]  Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
              RFC 9364, DOI 10.17487/RFC9364, February 2023,
              <https://www.rfc-editor.org/info/rfc9364>.

   [RFC9846]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
              <https://www.rfc-editor.org/info/rfc9846>.

14.2.  Informative References

   [RFC9102]  Dukhovni, V., Huque, S., Toorop, W., Wouters, P., and M.
              Shore, "TLS DNSSEC Chain Extension", RFC 9102,
              DOI 10.17487/RFC9102, August 2021,
              <https://www.rfc-editor.org/info/rfc9102>.

Huque & Dukhovni          Expires 15 March 2027                [Page 14]
Internet-Draft         TLSA client authentication         September 2026

   [RFC9156]  Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
              Name Minimisation to Improve Privacy", RFC 9156,
              DOI 10.17487/RFC9156, November 2021,
              <https://www.rfc-editor.org/info/rfc9156>.

   [SRVREG]   IANA, "Service Name and Transport Protocol Port Number
              Registry", <https://www.iana.org/assignments/service-
              names-port-numbers/service-names-port-numbers.txt>.

Authors' Addresses

   Shumon Huque
   Salesforce
   Email: shuque@gmail.com

   Viktor Dukhovni
   OpenSSL Corporation
   Email: ietf-dane@dukhovni.org

Huque & Dukhovni          Expires 15 March 2027                [Page 15]