idnits 2.17.1 draft-santesson-tls-certcache-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 (March 2009) is 5521 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Santesson (AAA-sec) 3 Intended Status: Proposed Standard 4 Expires September 2009 March 2009 6 TLS Cached Certificates Extension 7 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 This document defines a Transport Layer Security (TLS) extension for 33 cached certificates. This extension allows the TLS client to inform a 34 server of a previously cached server certificate path, allowing the 35 server to omit sending an identified certificate chain to the client 36 during the TLS handshake protocol exchange. 38 1. Introduction 40 A server certificate sent to the client during a TLS handshake can be 41 of considerable size. This is the case in particular if the server 42 certificate is bundled with a complete certificate path, including 43 all intermediary certificates up to the trust anchor public key. 45 Significant benefits can be achieved in low bandwidth and high 46 latency networks, in particular if the communication channel also has 47 a relatively high rate of transmission errors, if a known and 48 previously cached server certificate path can be omitted from the TLS 49 handshake. 51 This specification defines the CertCache TLS extension, which may be 52 used by a client to and a server to omit sending known certificate 53 data in the Server Certificate message. 55 1.1 Terminology 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [N1]. 61 2 Cached Certs Extension 63 A new extension type (cached_certs(TBD)) is defined and used in both 64 the client hello and server hello messages. The extension type is 65 specified as follows. 67 enum { 68 cached_certs(TBD), (65535) 69 } ExtensionType; 71 The "extension_data" field of this extension SHALL contain 72 "CachedCerts" containing a hash of cached server certificates: 74 struct { 75 opaque certificate_hash; <1..2^8-1> 76 } CachedCerts; 78 The certificate_hash value MUST include at least one hash value 79 calculated over an expected certificate_list element of a server side 80 Certificate message. 82 The hash algorithm used to generate hash included in certificate_hash 83 MUST be SHA-1. 85 4 Message flow 87 In order to allow negotiation to omit certificate data in the Server 88 Certificate message, the client MUST include an extension of type 89 "cached_certs" in the (extended) client hello, which SHALL contain at 90 least one certificate hash as specified in section 2. 92 Servers that receive an extended client hello containing a 93 "cached_certs" extension, MAY indicate that they are willing to 94 accept omitting certificate data in the Server Certificate message by 95 including an extension of type "cached_certs" in the (extended) 96 server hello, which SHALL contain a hash received in the cached_certs 97 extension from the client, which is a complete hash calculated over 98 all omitted certificates. 100 After negotiation of the use of cached certificates has been 101 successfully completed (by exchanging hello messages including 102 "cached_certs" extensions), the server MAY replace the 103 certificate_list element in its Certificate message with the hash 104 included in the cached_certs extension of the server hello message. 106 All operations of the handshake protocol will be processed as if the 107 hash value carried in the certificate_list element is the actual bits 108 of the server certificate path, with the only exception that all 109 public key operations will be done using the real certificates and 110 associated keys identified by the hash value. For example hash and 111 length values in the Finished message will be calculated over the 112 modified Server Certificate message (with omitted certificate data) 113 that was sent to the client. 115 5 Security Considerations 117 The use of hash algorithm in this specification requires reasonable 118 random properties in order to provide unique identifiers. No security 119 threat requires the hash algorithm to have strong collision 120 resistance. Consequently, there is no reason to provide hash agility 121 at the cost of protocol complexity. 123 6 IANA Considerations 125 TBD 127 7 Normative References 129 [N1] S. Bradner, "Key words for use in RFCs to Indicate 130 Requirement Levels", BCP 14, RFC 2119, March 1997. 132 TBD 134 Authors' Addresses 136 Stefan Santesson 137 AAA-sec AB 138 Bjornstorp 744 139 247 98 Genarp 140 Sweden 142 EMail: stefan@aaa-sec.com 144 Full Copyright Statement 146 Copyright (c) 2009 IETF Trust and the persons identified as the 147 document authors. All rights reserved. 149 This document is subject to BCP 78 and the IETF Trust's Legal 150 Provisions Relating to IETF Documents in effect on the date of 151 publication of this document (http://trustee.ietf.org/licenseinfo). 152 Please review these documents carefully, as they describe your rights 153 and restrictions with respect to this document. 155 All IETF Documents and the information contained therein are provided 156 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 157 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 158 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 159 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 160 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 161 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 162 FOR A PARTICULAR PURPOSE. 164 Expires September 2009