One document matched: draft-agl-tls-encryptedclientcerts-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
 <!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
 <!ENTITY RFC5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
]>

<?rfc toc="yes" symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-agl-tls-encryptedclientcerts-00">
  <front>
    <title abbrev="TLS Next Protocol Negotiation">Transport Layer Security (TLS) Encrypted Client Certificates</title>
    <author initials="A." surname="Langley" fullname="Adam Langley">
      <organization>Google Inc</organization>
      <address>
        <email>agl@google.com</email>
      </address>
    </author>
    <date month="October" year="2011" />
    <area>Security</area>
    <abstract>
      <t>
        This document describes a Transport Layer Security (TLS) extension that allows client certificates to be encrypted in the initial TLS handshake.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>
        <xref target="RFC5246">TLS</xref> defines a handshake in which both the server's and client's certificates (if any) are sent in the clear during the initial handshake. Although the server's certificates are usually non-sensitive, client certificates may include email address or even full legal names. Even client certificates that contain nothing but a serial number provide a unique identifier that can be correlated across connections by an eavesdropper.
      </t>

      <t>
        This motivates encrypting the client's certificates. One existing solution is to perform an initial handshake without client authentication and then to renegotiate with it. This solves the disclosure issue but at a significant cost in handshake overhead and latency. The solution presented below simply moves the client's certificates after the client's ChangeCipherSpec. This is fundamentally incompatable with DH or ECDH certificates but we note that such certificates are rarely used in our experience. This solution is also weak as it only defends against eavesdroppers, not active attackers. We still consider it worthwhile given the very low cost.
      </t>
    </section>

    <section title="Requirements Notation">
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
          target="RFC2119">RFC 2119</xref>.
      </t>
    </section>

    <section title="Encrypted client certificates extension">
      <t>
        A new extension type (<spanx style="verb">encrypted_client_certificates(provisionally 13180)</spanx>) is defined and MAY be included by the client in its <spanx style="verb">ClientHello</spanx> message. If, and only if, the server sees this extension in the <spanx style="verb">ClientHello</spanx>, it MAY choose to include the extension in its <spanx style="verb">ServerHello</spanx>. The <spanx style="verb">extension_data</spanx> MUST be empty in each case.
      </t>

      <figure>
        <artwork>
enum {
  encrypted_client_certificates(provisionally 13180), (65535)
} ExtensionType;
        </artwork>
      </figure>

      <t>
        If the extension is echoed by the server then encrypted client certificates are in effect for the handshake. This causes the client's second flow to be reordered so that the <spanx style="verb">Certificate</spanx> and <spanx style="verb">CertificateVerify</spanx> messages occur after the <spanx style="verb">ChangeCipherSpec</spanx>.
      </t>

      <t>
        Here is an example of the client's second flow without encrypted client certificates (taken from <xref target="RFC5246">RFC 5246</xref>):
      </t>

      <figure>
        <artwork>
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished
        </artwork>
      </figure>

      <t>
        When client encrypted certificates are in effect, this becomes:
      </t>

      <figure>
        <artwork>
ClientKeyExchange
[ChangeCipherSpec]
Certificate*
CertificateVerify*
Finished
        </artwork>
      </figure>

      <t>
        The <spanx style="verb">handshake_messages</spanx> value of the <spanx style="verb">CertificateVerify</spanx> is constructed using the new message order.
      </t>


      <t>
        This extension does not imply that a <spanx style="verb">CertificateRequest</spanx> handshake message will be sent by the server, nor that a <spanx style="verb">Certificate</spanx> or <spanx style="verb">CertificateVerify</spanx> message will be sent by the client. It only affects the message ordering when a client certificate would have normally been sent in the clear.
      </t>
    </section>

    <section title="Security considerations">
      <t>
        In the course of a normal handshake, the use of this extension will protect the client certificate from eavesdroppers. An active attacker can perform a downgrade attack and expose the client's certificates at the cost of dooming the connection. In order to defend against the active attack, a strict client may refuse to send certificates is the server doesn't support this extension in the initial handshake.
      </t>
    </section>

    <section title="IANA Considerations">
      <t>
        This document requires IANA to update its registry of TLS extensions
        to assign an entry, referred herein as <spanx style="verb">encrypted_client_certificates</spanx>.
      </t>
    </section>
    <section title="Acknowledgements">
      <t>
        Thanks to Wan-Teh Chang, Diana Smetters, Brian Smith, Adam Barth, Dirk
        Balfanz and Mayank Upadhyay for discussions around this design.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">

      &RFC2119;
      &RFC5246;

    </references>

    <section title="Changes">
      <t>To be removed by RFC Editor before publication</t>
    </section>
  </back>
</rfc>