[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits] [IPR]

Versions: 00

Network Working Group                                         A. Langley
Internet-Draft                                                Google Inc
Expires: April 26, 2012                                 October 24, 2011


      Transport Layer Security (TLS) Encrypted Client Certificates
                 draft-agl-tls-encryptedclientcerts-00

Abstract

   This document describes a Transport Layer Security (TLS) extension
   that allows client certificates to be encrypted in the initial TLS
   handshake.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, 2012.

Copyright Notice

   Copyright (c) 2011 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



Langley                  Expires April 26, 2012                 [Page 1]

Internet-Draft        TLS Next Protocol Negotiation         October 2011


   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 BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Encrypted client certificates extension  . . . . . . . . . . .  5
   4.  Security considerations  . . . . . . . . . . . . . . . . . . .  6
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
   Appendix A.  Changes . . . . . . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11



































Langley                  Expires April 26, 2012                 [Page 2]

Internet-Draft        TLS Next Protocol Negotiation         October 2011


1.  Introduction

   TLS [RFC5246] 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.

   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.






























Langley                  Expires April 26, 2012                 [Page 3]

Internet-Draft        TLS Next Protocol Negotiation         October 2011


2.  Requirements Notation

   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 RFC 2119 [RFC2119].














































Langley                  Expires April 26, 2012                 [Page 4]

Internet-Draft        TLS Next Protocol Negotiation         October 2011


3.  Encrypted client certificates extension

   A new extension type ("encrypted_client_certificates(provisionally
   13180)") is defined and MAY be included by the client in its
   "ClientHello" message.  If, and only if, the server sees this
   extension in the "ClientHello", it MAY choose to include the
   extension in its "ServerHello".  The "extension_data" MUST be empty
   in each case.

   enum {
     encrypted_client_certificates(provisionally 13180), (65535)
   } ExtensionType;

   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 "Certificate" and
   "CertificateVerify" messages occur after the "ChangeCipherSpec".

   Here is an example of the client's second flow without encrypted
   client certificates (taken from RFC 5246 [RFC5246]):

   Certificate*
   ClientKeyExchange
   CertificateVerify*
   [ChangeCipherSpec]
   Finished

   When client encrypted certificates are in effect, this becomes:

   ClientKeyExchange
   [ChangeCipherSpec]
   Certificate*
   CertificateVerify*
   Finished

   The "handshake_messages" value of the "CertificateVerify" is
   constructed using the new message order.

   This extension does not imply that a "CertificateRequest" handshake
   message will be sent by the server, nor that a "Certificate" or
   "CertificateVerify" 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.








Langley                  Expires April 26, 2012                 [Page 5]

Internet-Draft        TLS Next Protocol Negotiation         October 2011


4.  Security considerations

   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.










































Langley                  Expires April 26, 2012                 [Page 6]

Internet-Draft        TLS Next Protocol Negotiation         October 2011


5.  IANA Considerations

   This document requires IANA to update its registry of TLS extensions
   to assign an entry, referred herein as
   "encrypted_client_certificates".














































Langley                  Expires April 26, 2012                 [Page 7]

Internet-Draft        TLS Next Protocol Negotiation         October 2011


6.  Acknowledgements

   Thanks to Wan-Teh Chang, Diana Smetters, Brian Smith, Adam Barth,
   Dirk Balfanz and Mayank Upadhyay for discussions around this design.















































Langley                  Expires April 26, 2012                 [Page 8]

Internet-Draft        TLS Next Protocol Negotiation         October 2011


7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.












































Langley                  Expires April 26, 2012                 [Page 9]

Internet-Draft        TLS Next Protocol Negotiation         October 2011


Appendix A.  Changes

   To be removed by RFC Editor before publication
















































Langley                  Expires April 26, 2012                [Page 10]

Internet-Draft        TLS Next Protocol Negotiation         October 2011


Author's Address

   Adam Langley
   Google Inc

   Email: agl@google.com













































Langley                  Expires April 26, 2012                [Page 11]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/