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 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 RFC 2119 [RFC2119]. Langley Expires April 26, 2012 [Page 4]

Internet-Draft TLS Next Protocol Negotiation October 2011 3 . Encrypted client certificates extension 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 Langley Expires April 26, 2012 [Page 6]

Internet-Draft TLS Next Protocol Negotiation October 2011 5 . IANA Considerations Langley Expires April 26, 2012 [Page 7]

Internet-Draft TLS Next Protocol Negotiation October 2011 6 . Acknowledgements 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 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]