<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-dance-tls-clientid-01" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="TLS DANE ClientID Extension">TLS Extension for DANE Client Identity</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-dance-tls-clientid-01"/>
    <author fullname="Shumon Huque" initials="S." surname="Huque">
      <organization>Salesforce</organization>
      <address>
        <email>shuque@gmail.com</email>
      </address>
    </author>
    <author fullname="Viktor Dukhovni" initials="V." surname="Dukhovni">
      <organization>Two Sigma</organization>
      <address>
        <email>ietf-dane@dukhovni.org</email>
      </address>
    </author>
    <author fullname="Ash Wilson" initials="A." surname="Wilson">
      <organization>Valimail</organization>
      <address>
        <email>ash.wilson@valimail.com</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <date day="7" month="11" year="2022"/>
    <!-- Meta-data Declarations -->

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>TLS</keyword>
    <keyword>Extension</keyword>
    <keyword>DANE</keyword>
    <keyword>Client</keyword>
    <keyword>Identity</keyword>
    <abstract>
      <t>
	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.
      </t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>
	This document specifies a <xref target="RFC6066" format="default">
	Transport Layer Security (TLS) extension</xref> to convey a
	<xref target="RFC6698" format="default">DANE</xref>
	Client Identity to the TLS server. This is useful for
	applications that perform TLS client authentication
	via DANE TLSA records, as described in
	<xref target="DANECLIENT" format="default"/>. 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.
      </t>
      <t>
	This extension supports both TLS <xref target="RFC5246" format="default"/>
        <xref target="RFC8446" format="default"/> and <xref target="RFC6347" format="default">DTLS
        </xref>, and the term TLS in this document is used generically
	to describe both protocols.
      </t>
    </section>
    <section anchor="Overview" numbered="true" toc="default">
      <name>Overview</name>
      <t>
	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.
      </t>
      <t>
	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.
      </t>
      <t>
	When <xref target="RFC7250" format="default">TLS raw public
	keys</xref> 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).
      </t>
      <t>
	Detailed protocol behavior of TLS clients and servers is
	described in <xref target="DANECLIENT" format="default"/>.
      </t>
    </section>
    <section numbered="true" toc="default">
      <name>DANE Client Identity Extension</name>
      <t>
	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:
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[

opaque ClientName<1..2^8-1>;
        ]]></artwork>
      <t>
	The ClientName field contains the single domain name of
	the client in textual presentation format, as described in
	<xref target="RFC1035" format="default">RFC 1035</xref>,
        omitting the trailing dot.
      </t>
      <t>
	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.
      </t>
      <t>
	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.
      </t>
      <t>
        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.
      </t>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        In TLS 1.3, this extension is sent in the CertificateRequest
        and Certificate messages, which are encrypted.
      </t>
      <t>
        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.
      </t>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
	This extension requires the registration of a new value in the
	TLS ExtensionsType registry.
      </t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
        <front>
          <title>Domain names - implementation and specification</title>
          <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
            <organization/>
          </author>
          <date year="1987" month="November"/>
          <abstract>
            <t>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.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="13"/>
        <seriesInfo name="RFC" value="1035"/>
        <seriesInfo name="DOI" value="10.17487/RFC1035"/>
      </reference>
      <reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5246" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
          <author initials="T." surname="Dierks" fullname="T. Dierks">
            <organization/>
          </author>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization/>
          </author>
          <date year="2008" month="August"/>
          <abstract>
            <t>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]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5246"/>
        <seriesInfo name="DOI" value="10.17487/RFC5246"/>
      </reference>
      <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization/>
          </author>
          <date year="2018" month="August"/>
          <abstract>
            <t>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.</t>
            <t>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.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8446"/>
        <seriesInfo name="DOI" value="10.17487/RFC8446"/>
      </reference>
      <reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6066" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml">
        <front>
          <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
          <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
            <organization/>
          </author>
          <date year="2011" month="January"/>
          <abstract>
            <t>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]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6066"/>
        <seriesInfo name="DOI" value="10.17487/RFC6066"/>
      </reference>
      <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml">
        <front>
          <title>Datagram Transport Layer Security Version 1.2</title>
          <author initials="E." surname="Rescorla" fullname="E. Rescorla">
            <organization/>
          </author>
          <author initials="N." surname="Modadugu" fullname="N. Modadugu">
            <organization/>
          </author>
          <date year="2012" month="January"/>
          <abstract>
            <t>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]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6347"/>
        <seriesInfo name="DOI" value="10.17487/RFC6347"/>
      </reference>
      <reference anchor="RFC6698" target="https://www.rfc-editor.org/info/rfc6698" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml">
        <front>
          <title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</title>
          <author initials="P." surname="Hoffman" fullname="P. Hoffman">
            <organization/>
          </author>
          <author initials="J." surname="Schlyter" fullname="J. Schlyter">
            <organization/>
          </author>
          <date year="2012" month="August"/>
          <abstract>
            <t>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]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6698"/>
        <seriesInfo name="DOI" value="10.17487/RFC6698"/>
      </reference>
      <reference anchor="RFC7250" target="https://www.rfc-editor.org/info/rfc7250" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml">
        <front>
          <title>Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
          <author initials="P." surname="Wouters" fullname="P. Wouters" role="editor">
            <organization/>
          </author>
          <author initials="H." surname="Tschofenig" fullname="H. Tschofenig" role="editor">
            <organization/>
          </author>
          <author initials="J." surname="Gilmore" fullname="J. Gilmore">
            <organization/>
          </author>
          <author initials="S." surname="Weiler" fullname="S. Weiler">
            <organization/>
          </author>
          <author initials="T." surname="Kivinen" fullname="T. Kivinen">
            <organization/>
          </author>
          <date year="2014" month="June"/>
          <abstract>
            <t>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.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7250"/>
        <seriesInfo name="DOI" value="10.17487/RFC7250"/>
      </reference>
      <reference anchor="DANECLIENT" target="https://tools.ietf.org/html/draft-huque-dane-client-cert">
        <front>
          <title>TLS Client Authentication via DANE TLSA Records</title>
          <author fullname="Shumon Huque" initials="S" surname="Huque"/>
          <author fullname="Viktor Dukhovni" initials="V" surname="Dukhovni"/>
          <author fullname="Ash Wilson" initials="A" surname="Wilson"/>
          <date day="2" month="5" year="2021"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
