TLS Extension for DANE Client Identity
Internet-Draft draft-ietf-dance-tls-clientid-04
Shumon Huque
Salesforce
shuque@gmail.com
Viktor Dukhovni
Two Sigma
ietf-dane@dukhovni.org
2024-11-07
General
Internet Engineering Task Force
Internet-Draft
TLS
Extension
DANE
Client
Identity
This document specifies a TLS and DTLS extension to convey a DNS-Based Authentication of Named Entities (DANE) Client Identity to a TLS or DTLS server. This is useful for applications that perform TLS client authentication via DANE TLSA records.
Introduction
This document specifies a Transport Layer Security (TLS) extension to convey a DANE Client Identity to the TLS server. This is useful for applications that perform TLS client authentication via DANE TLSA records, as described in [DANECLIENT]. The extension could be empty to indicate to the server that the client has a DANE record and that the server can perform DANE authentication of the client with the identity extracted from the client certificate. Or the extension can contain the full client identity, in the form of the DNS domain name that is expected to have a DANE TLSA record published for it.
This extension supports both TLS [RFC5246] [RFC8446] and DTLS , and the term TLS in this document is used generically to describe both protocols. It is presently defined to work for both TLS 1.2 and 1.3 versions, and is expected to work with newer versions going forward.
Overview
When TLS clients use X.509 client certificates or raw public keys that are authenticated via DANE TLSA records, it is useful for them to convey their intent to be authenticated via DANE, or even to convey their complete DANE identity to the server. The TLS extension defined in this document is used to accomplish this.
In the case of X.509 client certificates, a TLS server can learn the client's identity by examining subject alternative names included in the certificate itself. However, without a mechanism such as the one defined in this extension, the TLS server cannot know apriori that the client has a published TLSA record, and thus may unnecessarily issue DNS queries for DANE TLSA records in-band with the TLS handshake even in cases where the client has no TLSA record associated with it. When multiple identities are present in the certificate, a client MUST use this extension to specify exactly which one the server should use. An additional situation in which this extension helps is where some TLS servers may need to selectively prompt for client certificate credentials only for clients that are equipped to provide certificates.
When TLS raw public keys are being used to authenticate the client, the client MUST use this extension to explicitly indicate to the server what its domain name identity is (since there is no X.509 certificate from which the identity can be extracted).
Detailed protocol behavior of TLS clients and servers is described in [DANECLIENT].
DANE Client Identity Extension
The DANE Client Identity Extension type, "dane_clientid", will have a value assigned and registered in the IANA TLS Extensions registry. Its extension data (if not empty) has the following format:

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

The ClientName field contains the single domain name of the client in textual presentation format, as described in RFC 1035, omitting the trailing dot.
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 an empty extension of type "dane_clientid" to indicate that it understands the extension and is capable of performing DANE client authentication. In TLS 1.2, the empty extension is sent in the ServerHello message. In TLS 1.3, it is sent in the CertificateRequest message.
A TLS client implementing this specification and intending to use DANE client authentication the TLS server, MUST send an extension of type "dane_clientid". If the client only needs to indicate that it has a DANE record and that the client's domain name identity can be obtained from its certificate, then the extension sent can be empty. If the client needs to send its domain name identity, then the "extension_data" field of the extension MUST contain a "ClientName" data structure populated with the domain name.
In TLS 1.2, the client extension is sent in the ClientHello message. In TLS 1.3, it is sent in the Certificate message. Additionally, in TLS 1.3, the client is only permitted to send the extension if it sees the corresponding empty extension in the server's CertificateRequest message.
Security Considerations
In TLS 1.3, this extension is sent in the CertificateRequest and Certificate messages, which are encrypted.
In TLS 1.2, this extension cannot be encrypted. When used with TLS 1.2, to prevent unnecessary privacy leakage of the client's name in cleartext, a TLS client implementing this specification should be configured to only send this extension to TLS servers it intends to perform client authentication with.
IANA Considerations
This extension requires the registration of a new value in the TLS ExtensionsType registry.
Normative References
[RFC1035]

Domain names - implementation and specification
P.V. Mockapetris
November 1987
STD 13
RFC 1035
DOI 10.17487/RFC1035
[RFC5246]

The Transport Layer Security (TLS) Protocol Version 1.2
T. Dierks
E. Rescorla
August 2008
RFC 5246
DOI 10.17487/RFC5246
[RFC8446]

The Transport Layer Security (TLS) Protocol Version 1.3
E. Rescorla
August 2018
RFC 8446
DOI 10.17487/RFC8446
[RFC6066]

Transport Layer Security (TLS) Extensions: Extension Definitions
D. Eastlake 3rd
January 2011
RFC 6066
DOI 10.17487/RFC6066
[RFC6347]

Datagram Transport Layer Security Version 1.2
E. Rescorla
N. Modadugu
January 2012
RFC 6347
DOI 10.17487/RFC6347
[RFC6698]

The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
P. Hoffman
J. Schlyter
August 2012
RFC 6698
DOI 10.17487/RFC6698
[RFC7250]

Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
P. Wouters, Ed.
H. Tschofenig, Ed.
J. Gilmore
S. Weiler
T. Kivinen
June 2014
RFC 7250
DOI 10.17487/RFC7250
[DANECLIENT]

TLS Client Authentication via DANE TLSA Records
Shumon Huque
Viktor Dukhovni
Ash Wilson
2021-05-02