idnits 2.17.00 (12 Aug 2021) /tmp/idnits45833/draft-ietf-tls-cached-info-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 26, 2011) is 3799 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) == Outdated reference: draft-ietf-tls-rfc4366-bis has been published as RFC 6066 ** Downref: Normative reference to an Informational RFC: RFC 3874 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' == Outdated reference: draft-iab-smart-object-workshop has been published as RFC 6574 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS S. Santesson 3 Internet-Draft 3xA Security AB 4 Intended status: Standards Track H. Tschofenig 5 Expires: June 28, 2012 Nokia Siemens Networks 6 December 26, 2011 8 Transport Layer Security (TLS) Cached Information Extension 9 draft-ietf-tls-cached-info-11.txt 11 Abstract 13 Transport Layer Security (TLS) handshakes often include fairly static 14 information, such as the server certificate and a list of trusted 15 Certification Authorities (CAs). This information can be of 16 considerable size, particularly if the server certificate is bundled 17 with a complete certificate path (including all intermediary 18 certificates up to the trust anchor public key). 20 This document defines an extension that omits the exchange of already 21 available information. The TLS client informs a server of cached 22 information, for example from a previous TLS handshake, allowing the 23 server to omit the already available information. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 28, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Cached Information Extension . . . . . . . . . . . . . . . . . 5 62 4. Exchange Specification . . . . . . . . . . . . . . . . . . . . 7 63 4.1. Fingerprint of the Certificate Chain . . . . . . . . . . . 7 64 4.2. Fingerprint for Trusted CAs . . . . . . . . . . . . . . . 8 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 6.1. New Entry to the TLS ExtensionType Registry . . . . . . . 11 68 6.2. New Registry for CachedInformationType . . . . . . . . . . 11 69 6.3. New Registry for HashAlgorithm . . . . . . . . . . . . . . 11 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 Transport Layer Security (TLS) handshakes often include fairly static 79 information, such as the server certificate and a list of trusted 80 Certification Authorities (CAs). This information can be of 81 considerable size, particularly if the server certificate is bundled 82 with a complete certificate path (including all intermediary 83 certificates up to the trust anchor public key). 85 Optimizing the exchange of information to a minimum helps to improve 86 performance in environments where devices are connected to a network 87 with characteristics like low bandwidth, high latency and high loss 88 rate. These types of networks exist, for example, when smart objects 89 are connected using a low power IEEE 802.15.4 radio. For more 90 information about the challenges with smart object deployments please 91 see [I-D.iab-smart-object-workshop]. 93 This specification defines a TLS extension that allows a client and a 94 server to exclude transmission of cached information from the TLS 95 handshake. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 3. Cached Information Extension 105 This document defines a new extension type (cached_information(TBD)), 106 which is used in client hello and server hello messages. The 107 extension type is specified as follows. 109 enum { 110 cached_information(TBD), (65535) 111 } ExtensionType; 113 The extension_data field of this extension, when included in the 114 client hello, MUST contain the CachedInformation structure. 116 enum { 117 certificate_chain(1), trusted_cas(2) (255) 118 } CachedInformationType; 120 struct { 121 CachedInformationType type; 122 HashAlgorithm hash; 123 opaque hash_value<1..255>; 124 } CachedObject; 126 struct { 127 CachedObject cached_info<1..2^16-1>; 128 } CachedInformation; 130 When the CachedInformationType identifies a certificate_chain, then 131 the hash_value field MUST include a hash calculated over the 132 certificate_list element of a server side Certificate message, 133 excluding the three length bytes of the certificate_list vector. 135 When the CachedInformationType identifies a trusted_cas, then the 136 hash_value MUST include a hash calculated over the 137 certificate_authorities element of a server side CertificateRequest 138 message, excluding the two length bytes of the 139 certificate_authorities vector. 141 The hash algorithm used to calculate hash values is conveyed in the 142 'hash' field of the CachedObject element. This document defines the 143 following hash algorithms: 145 o SHA-1: NIST FIPS PUB 180-3 [SHA] 146 o SHA-224: RFC 3874 [RFC3874] 148 o SHA-256: NIST FIPS PUB 180-3 [SHA] 150 o SHA-384: NIST FIPS PUB 180-3 [SHA] 152 o SHA-512: NIST FIPS PUB 180-3 [SHA] 154 This document establishes a registry for CachedInformationType types 155 and additional values can be added following the policy described in 156 Section 6. 158 4. Exchange Specification 160 Clients supporting this extension MAY include the 161 "cached_information" extension in the (extended) client hello, which 162 MAY contain zero or more CachedObject attributes. 164 Server supporting this extension MAY include the "cached_information" 165 extension in the (extended) server hello, which MAY contain one or 166 more CachedObject attributes. By returning the "cached_information" 167 extension the server indicates that it supports caching of each 168 present CachedObject that matches the specified hash value. The 169 server MAY support other cached objects that are not present in the 170 extension. 172 Note: Clients may need the ability to cache different values 173 depending on other information in the Client Hello that modify what 174 values the server uses, in particular the Server Name Indication 175 [I-D.ietf-tls-rfc4366-bis] value. 177 Following a successful exchange of "cached_information" extensions, 178 the server MAY send fingerprints of the cached information in the 179 handshake exchange as a replacement for the exchange of the full 180 data. Section 4.1 and Section 4.2 defines the syntax of the 181 fingerprinted information. 183 The handshake protocol MUST proceed using the information as if it 184 was provided in the handshake protocol. The Finished message MUST be 185 calculated over the actual data exchanged in the handshake protocol. 186 That is, the Finished message will be calculated over the hash values 187 of cached information objects and not over the cached information 188 that were omitted from transmission. 190 The server MUST NOT include more than one fingerprint for a single 191 information element, i.e., at maximum only one CachedObject structure 192 per replaced information is provided. 194 4.1. Fingerprint of the Certificate Chain 196 When an object of type 'certificate_chain' is provided in the client 197 hello, the server MAY send a fingerprint instead of the complete 198 certificate chain as shown below. 200 The original handshake message syntax is defined in RFC 5246 201 [RFC5246] and has the following structure: 203 opaque ASN.1Cert<1..2^24-1>; 205 struct { 206 ASN.1Cert certificate_list<0..2^24-1>; 207 } Certificate; 209 By using the extension defined in this document the following 210 information is sent: 212 struct { 213 CachedObject ASN.1Cert<1..2^24-1>; 214 } Certificate; 216 The opaque ASN.1Cert structure is replaced with the CachedObject 217 structure defined in this document. 219 Note: [I-D.wouters-tls-oob-pubkey] allows a PKIX certificate 220 containing only the SubjectPublicKeyInfo instead of the full 221 information typically found in a certificate. Hence, when this 222 specification is used in combination with 223 [I-D.wouters-tls-oob-pubkey] and the negotiated certificate type is 224 RawPublicKey then the TLS server sends the hashed Certificate element 225 that contains a ASN.1Cert with the mentioned raw public key. 227 4.2. Fingerprint for Trusted CAs 229 When a hash for an object of type 'trusted_cas' is provided in the 230 client hello, the server MAY send a fingerprint instead of the 231 complete certificate authorities information as shown below. 233 The original handshake message syntax is defined in RFC 5246 234 [RFC5246] and has the following structure: 236 opaque DistinguishedName<1..2^16-1>; 238 struct { 239 ClientCertificateType certificate_types<1..2^8-1>; 240 SignatureAndHashAlgorithm 241 supported_signature_algorithms<2^16-1>; 242 DistinguishedName certificate_authorities<0..2^16-1>; 243 } CertificateRequest; 245 By using the extension defined in this document the following 246 information is sent: 248 struct { 249 ClientCertificateType certificate_types<1..2^8-1>; 250 SignatureAndHashAlgorithm 251 supported_signature_algorithms<2^16-1>; 252 CachedObject DistinguishedName<1..2^16-1>; 253 } CertificateRequest; 255 The opaque DistinguishedName structure is replaced with the 256 CachedObject structure defined in this document. 258 5. Security Considerations 260 The hash algorithm used in this specification is required to have 261 reasonable random properties in order to provide reasonably unique 262 identifiers. There is no requirement that this hash algorithm must 263 have strong collision resistance. 265 Caching information in an encrypted handshake (such as a renegotiated 266 handshake) and sending a hash of that cached information in an 267 unencrypted handshake might introduce integrity or data disclosure 268 issues as it enables an attacker to identify if a known object (such 269 as a known server certificate) has been used in previous encrypted 270 handshakes. Information object types defined in this specification, 271 such as server certificates, are public objects and usually not 272 sensitive in this regard, but implementers should be aware if any 273 cached information are subject to such security concerns and in such 274 case SHOULD NOT send a hash over encrypted data in en unencrypted 275 handshake. 277 6. IANA Considerations 279 6.1. New Entry to the TLS ExtensionType Registry 281 IANA is requested to add an entry to the existing TLS ExtensionType 282 registry, defined in RFC 5246 [RFC5246], for cached_information(TBD) 283 defined in this document. 285 6.2. New Registry for CachedInformationType 287 IANA is requested to establish a registry for TLS 288 CachedInformationType values. The first entries in the registry are 290 o certificate_chain(1) 292 o trusted_cas(2) 294 The policy for adding new values to this registry, following the 295 terminology defined in RFC 5226 [RFC5226], is as follows: 297 o 0-63 (decimal): Standards Action 299 o 64-223 (decimal): Specification Required 301 o 224-255 (decimal): reserved for Private Use 303 6.3. New Registry for HashAlgorithm 305 IANA is requested to establish a registry for HashAlgorithm values 306 and to populate the registry with an initial set of values listed in 307 Section 3. 309 The policy for adding new values to this registry, following the 310 terminology defined in RFC 5226 [RFC5226], is as follows: 312 o 0-63 (decimal): Standards Action 314 o 64-223 (decimal): Specification Required 316 o 224-255 (decimal): reserved for Private Use 318 7. Acknowledgments 320 The author acknowledges input from many members of the TLS working 321 group. 323 We would like to thank Paul Wouters for his feedback and Nikos 324 Mavrogiannopoulos for his document review in December 2011. 326 8. References 328 8.1. Normative References 330 [I-D.ietf-tls-rfc4366-bis] 331 3rd, D., "Transport Layer Security (TLS) Extensions: 332 Extension Definitions", draft-ietf-tls-rfc4366-bis-12 333 (work in progress), September 2010. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", 339 RFC 3874, September 2004. 341 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 342 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 344 [SHA] "Federal Information Processing Standards Publication 345 (FIPS PUB) 180-3, Secure Hash Standard (SHS)", 346 October 2008. 348 8.2. Informative References 350 [I-D.iab-smart-object-workshop] 351 Tschofenig, H. and J. Arkko, "Report from the 352 'Interconnecting Smart Objects with the Internet' 353 Workshop, 25th March 2011, Prague", 354 draft-iab-smart-object-workshop-06 (work in progress), 355 October 2011. 357 [I-D.wouters-tls-oob-pubkey] 358 Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H. 359 Tschofenig, "TLS out-of-band public key validation", 360 draft-wouters-tls-oob-pubkey-02 (work in progress), 361 November 2011. 363 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 364 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 365 May 2008. 367 Authors' Addresses 369 Stefan Santesson 370 3xA Security AB 371 Scheelev. 17 372 Lund 223 70 373 Sweden 375 Email: sts@aaa-sec.com 377 Hannes Tschofenig 378 Nokia Siemens Networks 379 Linnoitustie 6 380 Espoo 02600 381 Finland 383 Phone: +358 (50) 4871445 384 Email: Hannes.Tschofenig@gmx.net 385 URI: http://www.tschofenig.priv.at