idnits 2.17.1 draft-thomson-tls-offline-config-00.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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 19, 2015) is 3110 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: A later version (-28) exists of draft-ietf-tls-tls13-09 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track October 19, 2015 5 Expires: April 21, 2016 7 Offline Server Configuration for Zero Round Trip Transport Layer 8 Security 9 draft-thomson-tls-offline-config-00 11 Abstract 13 Zero round trip operation in TLS relies on a client knowing about a 14 server configuration prior to establishing a connection. TLS 15 provides a mechanism for a server to provide a configuration during a 16 handshake so that subsequent connections can send encrypted data in 17 its first flight of messages. This document defines a format for 18 this configuration information that can be used outside of TLS. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 21, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Offline Server Configuration Format . . . . . . . . . . . . . 3 57 2.1. Offline Configuration Authentication . . . . . . . . . . 3 58 3. Server Configuration Extensions . . . . . . . . . . . . . . . 4 59 3.1. Server Cipher Suites . . . . . . . . . . . . . . . . . . 4 60 3.2. Certificate . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Certificate Request . . . . . . . . . . . . . . . . . . . 5 62 3.4. Supported Groups . . . . . . . . . . . . . . . . . . . . 6 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 6.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 A client that establishes a TLS connection to a server is unable to 74 send any encrypted data to the server prior to receiving a server 75 configuration. This introduces a minimum of one round trip of 76 latency to TLS connections. 78 TLS 1.3 [I-D.ietf-tls-tls13] describes a zero round trip mode of 79 operation that allows a client to send replayable data to a server. 80 A server configuration is provided to clients in an initial 81 handshake. That configuration is used by the client to encrypt the 82 first flight of messages it sends in subsequent connections. While 83 this first flight of messages can be replayed by an attacker, it has 84 both confidentiality and integrity protection. This enables use 85 cases where the need to reduce latency is important, but replay 86 protection is either not needed, or provided by other means. 88 This document describes how a server configuration can be established 89 outside of the TLS handshake. This allows for alternative methods of 90 delivery for the server configuration. 92 1.1. Terminology 94 RFC 2119 [RFC2119] defines the terms MUST, SHOULD, and MAY. 96 2. Offline Server Configuration Format 98 The offline server configuration is simply a ServerConfiguration, 99 that is optionally signed. 101 struct { 102 ServerConfiguration config; 103 digitally-signed struct { 104 ServerConfiguration config; 105 }; 106 } OfflineServerConfiguration; 108 Figure 1: OfflineServerConfiguration Definition 110 Extensions to the ServerConfiguration object are used to convey the 111 additional information needed for use outside of the TLS handshake 112 are defined in Section 3. An offline configuration MUST include the 113 certificate and server_cipher_suites extensions. An offline 114 configuration that requests or permits client authentication MUST 115 include the certificate_request extension. 117 2.1. Offline Configuration Authentication 119 A client MUST NOT use an offline server configuration unless it has 120 been successfully authenticated. This includes signature validation, 121 plus additional checks on the included certificate. 123 The signature MUST be validated against the public key in the 124 included end-entity certificate (that is, the first certificate in 125 the list of provided certificates, if more than one is included). 127 The process for constructing and verifying digital signatures is 128 defined in [I-D.ietf-tls-tls13]. The context string for the 129 signature on an offline server configuration is "TLS 1.3, offline 130 ServerConfiguration". 132 The signature and hash algorithm that are used for signing can be any 133 value that the server supports, provided that it is compatible with 134 the key in the server's end-entity certificate or public key 135 [RFC7250]. A client that does not support the algorithms that the 136 server selects will simply be unable to use the configuration. 138 A client MUST NOT use an offline server configuration unless the end- 139 entity certificate or public key is successfully validated according 140 to the rules for the using protocol and application (such as 141 [RFC2818] or [RFC6125]). 143 3. Server Configuration Extensions 145 The offline server configuration uses the same ServerConfiguration 146 format that is defined in [I-D.ietf-tls-tls13], with extensions to 147 carry the additional information that a client would ordinarily 148 obtain from the TLS handshake. 150 enum { 151 server_cipher_suites(0), certificate(1), 152 certificate_request(2), supported_groups(3), 153 (65535) 154 } ConfigurationExtensionType; 156 struct { 157 ConfigurationExtensionType extension_type; 158 uint16 length; 159 select (extension_type) { 160 case server_cipher_suites: 161 ServerCipherSuites; 162 case certificate: 163 Certificate; 164 case certificate_request: 165 CertificateRequest; 166 case supported_groups: 167 NamedGroupList; 168 } extension_data; 169 } ConfigurationExtension; 171 Figure 2: ServerConfiguration Extension Additions 173 Section 3 shows a modified version of the ConfigurationExtension 174 structure from [I-D.ietf-tls-tls13] that includes the extensions 175 added in this document. These extensions are defined in detail in 176 subsequent sections. 178 3.1. Server Cipher Suites 180 A server configuration that appears in a TLS handshake is implicitly 181 bound to the cipher suite that was negotiated in that handshake. 182 Outside of a TLS handshake, a client need to be able to know which 183 cipher suites are supported by the server. 185 The "server_cipher_suites" extension to ServerConfiguration 186 identifies the set of cipher suites that the server is willing to 187 use. This only applies to the replayable data that the client sends 188 in its first flight; the remainder of the handshake is protected 189 using a cipher suite that is negotiated in the usual fashion. This 190 implies that the replayable data may be protected with a different 191 symmetric algorithm than the server ultimately selects. The key 192 exchange and signature algorithms MUST be the same. 194 CipherSuite ServerCipherSuites<2..2^16-2>; 196 Figure 3: ServerCipherSuites Extension Format 198 An offline server configuration MUST NOT be used if it does not 199 include the "server_cipher_suites" extension. 201 A client can choose any cipher suite from this set for protecting its 202 first flight. The client MUST include the selected value in the 203 cipher_suites field of its ClientHello. A server MAY reject either 204 the replayable data or the entire handshake if the client selects a 205 cipher suite that it does not claim to support. 207 A server MAY choose to offer a smaller set of cipher suites for use 208 in the client's first flight than it might support for a complete TLS 209 handshake. 211 Clients MUST NOT alter the set of cipher suites they offer based on 212 the value seen in a ServerConfiguration. While a falsified 213 ServerConfiguration might permit an attacker to decrypt replayable 214 data, altering the set of cipher suites would also permit a cipher 215 suite downgrade attack. 217 3.2. Certificate 219 The content of the "certificate" server configuration extension is 220 identical to that of the Certificate handshake message in both syntax 221 and semantics. Note however that the ServerConfiguration extension 222 limits the size of the certificate chain to 65535 octets. 224 3.3. Certificate Request 226 The content of the "certificate_request" server configuration 227 extension is identical to that of the CertificateRequest message that 228 a server sends to request that a client authenticate in both syntax 229 and semantics. This is included to allow the client to generate 230 Certificate and CertificateVerify messages that the server is able to 231 use. 233 Including the "certificate_request" extension is only necessary when 234 the server configuration permits client authentication. That is, 235 when the "early_data_type" is set to either "client_authentication" 236 or "client_authentication_and_data". 238 3.4. Supported Groups 240 The content of the "supported_groups" server configuration extension 241 is identical to that of the "supported_groups" hello extension in 242 both syntax and semantics. The extension carries a NamedGroupList 243 object as defined in [I-D.ietf-tls-tls13]. This is used by a client 244 to select a client certificate for which a signature can be 245 successfully consumed by the server. 247 4. Security Considerations 249 Enabling zero round trip TLS in this fashion does not alter the 250 limitations of sending data in the client's first flight of messages. 251 In particular, the first flight of data from the client is not 252 protected from replay. Details of these limitations are provided in 253 [I-D.ietf-tls-tls13]. 255 Server configurations that are generated offline MUST include a 256 signature. Failure to properly authenticate a server configuration 257 (see Section 2.1) can allow an attacker to substitute keying 258 material, allowing data that was intended for a specific server to be 259 encrypted toward a server of an attacker's choosing. Though the 260 first flight from the client is not protected from replay, this would 261 violate the integrity and confidentiality guarantees that are 262 provided. 264 5. IANA Considerations 266 This document registers the following ServerConfiguration extensions 267 in the registry established by [I-D.ietf-tls-tls13]: 269 o server_cipher_suites (Section 3.1) 271 o certificate (Section 3.2) 273 o certificate_request (Section 3.3) 275 o supported_groups (Section 3.4) 277 6. References 279 6.1. Normative References 281 [I-D.ietf-tls-tls13] 282 Rescorla, E., "The Transport Layer Security (TLS) Protocol 283 Version 1.3", draft-ietf-tls-tls13-09 (work in progress), 284 October 2015. 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 288 RFC2119, March 1997, 289 . 291 6.2. Informative References 293 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 294 RFC2818, May 2000, 295 . 297 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 298 Verification of Domain-Based Application Service Identity 299 within Internet Public Key Infrastructure Using X.509 300 (PKIX) Certificates in the Context of Transport Layer 301 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 302 2011, . 304 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 305 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 306 Transport Layer Security (TLS) and Datagram Transport 307 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 308 June 2014, . 310 Appendix A. Acknowledgements 312 This document is better for the contributions of Karthikeyan 313 Bhargavan, Wan-Teh Chang, Christian Huitema, Adam Langley, Eric 314 Rescorla, and others. 316 Author's Address 318 Martin Thomson 319 Mozilla 321 Email: martin.thomson@gmail.com