idnits 2.17.1 draft-agl-tls-encryptedclientcerts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2011) is 4566 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 123, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Langley 3 Internet-Draft Google Inc 4 Expires: April 26, 2012 October 24, 2011 6 Transport Layer Security (TLS) Encrypted Client Certificates 7 draft-agl-tls-encryptedclientcerts-00 9 Abstract 11 This document describes a Transport Layer Security (TLS) extension 12 that allows client certificates to be encrypted in the initial TLS 13 handshake. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 26, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 57 3. Encrypted client certificates extension . . . . . . . . . . . 5 58 4. Security considerations . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 61 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 62 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 10 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 1. Introduction 67 TLS [RFC5246] defines a handshake in which both the server's and 68 client's certificates (if any) are sent in the clear during the 69 initial handshake. Although the server's certificates are usually 70 non-sensitive, client certificates may include email address or even 71 full legal names. Even client certificates that contain nothing but 72 a serial number provide a unique identifier that can be correlated 73 across connections by an eavesdropper. 75 This motivates encrypting the client's certificates. One existing 76 solution is to perform an initial handshake without client 77 authentication and then to renegotiate with it. This solves the 78 disclosure issue but at a significant cost in handshake overhead and 79 latency. The solution presented below simply moves the client's 80 certificates after the client's ChangeCipherSpec. This is 81 fundamentally incompatable with DH or ECDH certificates but we note 82 that such certificates are rarely used in our experience. This 83 solution is also weak as it only defends against eavesdroppers, not 84 active attackers. We still consider it worthwhile given the very low 85 cost. 87 2. Requirements Notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 3. Encrypted client certificates extension 95 A new extension type ("encrypted_client_certificates(provisionally 96 13180)") is defined and MAY be included by the client in its 97 "ClientHello" message. If, and only if, the server sees this 98 extension in the "ClientHello", it MAY choose to include the 99 extension in its "ServerHello". The "extension_data" MUST be empty 100 in each case. 102 enum { 103 encrypted_client_certificates(provisionally 13180), (65535) 104 } ExtensionType; 106 If the extension is echoed by the server then encrypted client 107 certificates are in effect for the handshake. This causes the 108 client's second flow to be reordered so that the "Certificate" and 109 "CertificateVerify" messages occur after the "ChangeCipherSpec". 111 Here is an example of the client's second flow without encrypted 112 client certificates (taken from RFC 5246 [RFC5246]): 114 Certificate* 115 ClientKeyExchange 116 CertificateVerify* 117 [ChangeCipherSpec] 118 Finished 120 When client encrypted certificates are in effect, this becomes: 122 ClientKeyExchange 123 [ChangeCipherSpec] 124 Certificate* 125 CertificateVerify* 126 Finished 128 The "handshake_messages" value of the "CertificateVerify" is 129 constructed using the new message order. 131 This extension does not imply that a "CertificateRequest" handshake 132 message will be sent by the server, nor that a "Certificate" or 133 "CertificateVerify" message will be sent by the client. It only 134 affects the message ordering when a client certificate would have 135 normally been sent in the clear. 137 4. Security considerations 139 In the course of a normal handshake, the use of this extension will 140 protect the client certificate from eavesdroppers. An active 141 attacker can perform a downgrade attack and expose the client's 142 certificates at the cost of dooming the connection. In order to 143 defend against the active attack, a strict client may refuse to send 144 certificates is the server doesn't support this extension in the 145 initial handshake. 147 5. IANA Considerations 149 This document requires IANA to update its registry of TLS extensions 150 to assign an entry, referred herein as 151 "encrypted_client_certificates". 153 6. Acknowledgements 155 Thanks to Wan-Teh Chang, Diana Smetters, Brian Smith, Adam Barth, 156 Dirk Balfanz and Mayank Upadhyay for discussions around this design. 158 7. Normative References 160 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 161 Requirement Levels", BCP 14, RFC 2119, March 1997. 163 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 164 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 166 Appendix A. Changes 168 To be removed by RFC Editor before publication 170 Author's Address 172 Adam Langley 173 Google Inc 175 Email: agl@google.com