TLS Extension for DANE Client Identity
Salesforce
shuque@gmail.com
Two Sigma
ietf-dane@dukhovni.org
Valimail
ash.wilson@valimail.com
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
. 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
and DTLS
, and the term TLS in this document is used generically
to describe both protocols.
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 uses 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 .
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:
;
]]>
The ClientName field contains the single domain name of
the client in textual presentation format, as described in
RFC 1035,
omitting the trailing dot.
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 SHOULD 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
Domain names - implementation and specification
This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.
The Transport Layer Security (TLS) Protocol Version 1.2
This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]
The Transport Layer Security (TLS) Protocol Version 1.3
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.
Transport Layer Security (TLS) Extensions: Extension Definitions
This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]
Datagram Transport Layer Security Version 1.2
This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]
The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]
Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.
TLS Client Authentication via DANE TLSA Records