Internet Engineering Task Force S. Huque
Internet-Draft Salesforce
Intended status: Standards Track V. Dukhovni
Expires: August 23, 2017 Two Sigma
February 19, 2017
TLS Extension for DANE Client Identitydraft-huque-tls-dane-clientid-01
Abstract
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.
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 http://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 August 23, 2017.
Copyright Notice
Copyright (c) 2017 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
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Huque & Dukhovni Expires August 23, 2017 [Page 1]

Internet-Draft TLS DANE ClientID Extension February 2017
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 can 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 [RFC7250] are being used to authenticate the
client, the client uses this extension to explicitly indicate to the
server what its domain name identity is.
Detailed protocol behavior of TLS clients and servers is described in
[DANECLIENT].
3. 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.
A TLS client implementing this specification SHOULD send an extension
of type "dane_clientid" in the ClientHello handshake message to TLS
servers it intends to perform DANE client authentication with.
The "extension_data" field of the extension MUST contain a
"DaneClientName" data structure defined in the following format:
Huque & Dukhovni Expires August 23, 2017 [Page 3]

Internet-Draft TLS DANE ClientID Extension February 2017
enum {
dns_name(0), srv_name(1), (255)
} NameType;
opaque dNSName<1..2^16-1>;
opaque SRVName<1..2^16-1>;
struct {
NameType name_type;
select (name_type) {
case dns_name: dNSName;
case srv_name: SRVName;
} name;
} DaneClientName;
The opaque dNSName or SRVName field contains the domain name of the
client in textual presentation format, as described in RFC 1035
[RFC1035].
4. Open Questions
Should multiple client names be supported in the extension?
Is the dNSName/SRVName distinction useful, or can we just simplify
and use only dNSName? These two name forms are analogous to the two
recommended for use in X.509 certificates in the DANE client
authentication draft, so the server could use this to additionally
check against the corresponding certificate fields (but does it need
to?). If the server needs a hint of whether to construct an
application specific ID, then this might be useful, but this could
also be inferred from the structure of the name and the client could
just specify an application specific identity in the dNSName type.
The extension is defined in terms of a DANE specific identity. Is
there a need for a more general purpose client name indication
extension? If so, this extension could be renamed and augmented to
have an additional usage field containing values denoting DANE or
alternative application usages.
5. Security Considerations
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.
Huque & Dukhovni Expires August 23, 2017 [Page 4]