idnits 2.17.1 draft-gutmann-tls-lts-07.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 date (February 5, 2017) is 2635 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '32' is mentioned on line 225, but not defined ** Obsolete normative reference: RFC 5246 (ref. '2') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (ref. '5') (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7507 (ref. '7') (Obsoleted by RFC 8996) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 3447 (ref. '10') (Obsoleted by RFC 8017) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group P. Gutmann 3 Internet-Draft University of Auckland 4 Intended status: Standards Track February 5, 2017 5 Expires: August 9, 2017 7 TLS 1.2 Update for Long-term Support 8 draft-gutmann-tls-lts-07 10 Abstract 12 This document specifies an update of TLS 1.2 for long-term support on 13 systems that can have multi-year or even decade-long update cycles, 14 one that incoporates as far as possible what's already deployed for 15 TLS 1.2 but with the security holes and bugs fixed. This document 16 also recognises the fact that there is a huge amount of TLS use 17 outside the web content-delivery environment with its resource-rich 18 hardware and software that can be updated whenever required and 19 provides a long-term stable, known-good version that can be deployed 20 to systems that can't roll out ongoing changes on a continuous basis. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 9, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 58 2. TLS-LTS Negotiation . . . . . . . . . . . . . . . . . . . . . 3 59 3. TLS-LTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Encryption/Authentication . . . . . . . . . . . . . . . . 4 61 3.2. Message Formats . . . . . . . . . . . . . . . . . . . . . 6 62 3.3. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 7 63 3.4. Implementation Issues . . . . . . . . . . . . . . . . . . 8 64 3.5. Use of TLS Extensions . . . . . . . . . . . . . . . . . . 11 65 3.6. Downgrade Attack Prevention . . . . . . . . . . . . . . . 13 66 3.7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 13 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 4.1. Security Properties Provided by TLS-LTS . . . . . . . . . 15 69 4.2. Security Properties Not Provided by TLS-LTS . . . . . . . 15 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 74 7.2. Informative References . . . . . . . . . . . . . . . . . 17 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 77 1. Introduction 79 TLS [2] and DTLS [5], by nature of their enormous complexity and the 80 inclusion of large amounts of legacy material, contain numerous 81 security issues that have been known to be a problem for many years 82 and that keep coming up again and again in attacks (there are too 83 many of these to provide references for in the standard manner, and 84 in any case more will have been published by the time you read this). 85 This document presents a minimal, known-good set of mechanisms that 86 defend against all currently-known weaknesses in TLS, that would have 87 defended against them ten years ago, and that have a good chance of 88 defending against them ten years from now, providing the long-term 89 stability that's required by many systems in the field. This long- 90 term stability is particularly important in light of the fact that 91 widespread mainstream adoption of new versions of TLS has been shown 92 to take 15 years or more [25], with adoption in embedded environments 93 taking even longer. 95 In particular, this document takes inspiration from numerous 96 published analyses of TLS [11] [12] [13] [14] [15] [16] [17] [18] 98 [19] [20] [21] [22] [23] [24] along with two decades of 99 implementation and deployment experience to select a standard 100 interoperable feature set that provides the best chance of long-term 101 stability and resistance to attack. This is intended for use in 102 systems that need to run in a fixed configuration for a long period 103 of time after they're deployed, with little or no ability to roll out 104 patches every month or two when the next attack on TLS is published. 106 Unlike the full TLS 1.2, TLS-LTS is not meant to be all things to all 107 people. It represents a fixed, safe solution that's appropriate for 108 users who require a simple, secure, and long-term stable means of 109 getting data from A to B. This represents the majority of the non- 110 browser uses of TLS, particularly for embedded systems that are most 111 in need of a long-term stable protocol definition. 113 [Note: There is currently a TLS 1.2 LTS test server running 114 at https://82.94.251.205:8443. This uses the extension 115 value 26 until a value is permanently assigned for LTS 116 use. To connect, your implementation should accept 117 whatever certificate is presented by the server or use PSK 118 with name = "plc", password = "test". For embedded 119 systems testing, note that the server talks HTTP and not 120 DNP3 or ICCP, so you'll get an error if you try and connect 121 with a PLC control centre that expects one of those 122 protocols]. 124 1.1. Conventions Used in This Document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [1]. 130 2. TLS-LTS Negotiation 132 The use of TLS-LTS is negotiated via TLS/DTLS extensions as defined 133 in TLS Extensions [4]. On connecting, the client includes the 134 tls_lts extension in its Client Hello if it wishes to use TLS-LTS. 135 If the server is capable of meeting this requirement, it responds 136 with a tls_lts extension in its Server Hello. The "extension_type" 137 value for this extension MUST be TBD (0xTBD) and the "extension_data" 138 field of this extension is empty. The client and server MUST NOT use 139 TLS-LTS unless both sides have successfully exchanged tls_lts 140 extensions. 142 Note that the TLS-LTS extension applies to TLS 1.2, not to any 143 earlier version of TLS. If a client requests the use of TLS-LTS in 144 its client_hello but the server falls back to TLS 1.1 or earlier, it 145 MUST NOT indicate the use of TLS- LTS in its server_hello. 147 In the case of session resumption, once TLS-LTS has been negotiated 148 implementations MUST retain the use of TLS-LTS across all subsequent 149 resumed sessions. In other words if TLS-LTS is enabled for the 150 current session then the resumed session MUST also use TLS-LTS. If a 151 client or server attempts to resume a TLS-LTS session as a non-TLS- 152 LTS session then the peer MUST abort the handshake. 154 3. TLS-LTS 156 TLS-LTS specifies a few simple restrictions on the huge range of TLS 157 suites, options and parameters to limit the protocol to a known-good 158 subset, as well as making minor corrections to prevent or at least 159 limit various attacks. 161 3.1. Encryption/Authentication 163 TLS-LTS restricts the more or less unlimited TLS 1.2 with its more 164 than three hundred cipher suites, over forty ECC parameter sets, and 165 zoo of supplementary algorithms, parameters, and parameter formats, 166 to just two, one traditional one with DHE + AES-CBC + HMAC-SHA-256 + 167 RSA-SHA-256/PSK and one ECC one with ECDHE-P256 + AES-GCM + HMAC- 168 SHA-256 + ECDSA-P256-SHA-256/PSK with uncompressed points: 170 o TLS-LTS implementations MUST support 171 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, 172 TLS_DHE_PSK_WITH_AES_128_CBC_SHA256, 173 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 174 TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256. For these suites, SHA-256 175 is used in all locations in the protocol where a hash function is 176 required, specifically in the PRF and per-packet MAC calculations 177 (as indicated by the _SHA256 in the suite) and also in the client 178 and server signatures in the CertificateVerify and 179 ServerKeyExchange messages. 181 [Note: There's a gap in the suites with 182 TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 missing, there's 183 currently a draft in progress to fill the gap, 184 draft-mattsson-tls-ecdhe-psk-aead, which can be used to 185 replace the placeholder TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256]. 187 TLS-LTS only permits encrypt-then-MAC, not MAC-then-encrypt, fixing 188 20 years of attacks on this mechanism: 190 o TLS-LTS implementations MUST implement encrypt-then-MAC [6] rather 191 than the earlier MAC-then-encrypt. 193 TLS-LTS adds a hash of all messages leading up to the calculation of 194 the master secret into the master secret to protect against the use 195 of manipulated handshake parameters: 197 o TLS-LTS implementations MUST implement extended master secret [8] 198 to protect handshake and crypto parameters. 200 TLS-LTS drops the MAC truncation in the Finished message, which 201 serves no obvious purpose and leads to security concerns: 203 o The length of verify_data (verify_data_length) in the Finished 204 message MUST be equal to the length of the output of the hash 205 function used for the PRF. For the mandatory TLS-LTS cipher 206 suites this hash is always SHA-256, so the value of 207 verify_data_length will be 32 bytes. For other suites, the size 208 depends on the hash algorithm associated with the suite. For 209 example for SHA-512 it would be 64 bytes. 211 TLS-LTS signs a hash of the client and server hello messages for the 212 ServerKeyExchange rather than signing just the client and server 213 nonces, avoiding various attacks that build on the fact that standard 214 TLS doesn't authenticate previously-exchanged parameters when the 215 ServerKeyExchange message is sent: 217 o When generating the ServerKeyExchange signature, the signed_params 218 value is updated to replace the client_random and server_random 219 with a hash of the full Client Hello and Server Hello using the 220 hash algorithm for the chosen cipher suite. In other words the 221 value being signed is changed from: 223 digitally-signed struct { 224 opaque client_random[32]; 225 opaque server_random[32]; 226 ServerDHParams params; 227 } signed_params; 229 to: 231 digitally-signed struct { 232 opaque client_server_hello_hash; 233 ServerDHParams params; 234 } signed_params; 236 For the mandatory TLS-LTS cipher suites the hash algorithm is 237 always SHA-256, so the length of the client_server_hello_hash is 238 32 bytes. For other suites, the size depends on the hash 239 algorithm associated with the suite. For example for SHA-512 it 240 would be 64 bytes. 242 (In terms of side-channel attack prevention, it would be preferable 243 to include a non-public quantity into the data being signed since 244 this reduces the scope of attack from a passive to an active one, 245 with the attacker needing to initiate their own handshakes in order 246 to carry out their attack. However no shared secret value has been 247 established at this point so only public data can be signed). 249 The choice of key sizes is something that will never get any 250 consensus because there are so many different worldviews involved. 251 TLS-LTS makes only general recommendations on best practices and 252 leaves the choice of which key sizes are appropriate to implementers 253 and policy makers: 255 o Implementations SHOULD choose public-key algorithm key sizes that 256 are appropriate for the situation, weighted by the value of the 257 information being protected, the probability of attack and 258 capabilities of the attacker(s), any relevant security policies, 259 and the ability of the system running the TLS implementation to 260 deal with the computational load of large keys. For example a 261 SCADA system being used to switch a ventilator on and off doesn't 262 require anywhere near the keysize-based security of a system used 263 to transfer classified data. 265 One way to avoid having to use very large public keys is to switch 266 the keys periodically. For example for DH keys this can be done by 267 regenerating DH parameters in a background thread and rolling them 268 over from time to time. If this isn't possible, an alternative 269 option is to pre-generate a selection of DH parameters and choose one 270 set at random for each new handshake, or again roll them over from 271 time to time from the pre-generated selection, so that an attacker 272 has to attack multiple sets of parameters rather than just one. 274 3.2. Message Formats 276 TLS-LTS sends the full set of DH parameters, X9.42/FIPS 186 style, 277 not p and g only, PKCS #3 style. This allows verification of the DH 278 parameters, which the current format doesn't allow: 280 o TLS-LTS implementations MUST send the DH domain parameters as { p, 281 q, g } rather than { p, g }. This makes the ServerDHParams field: 283 struct { 284 opaque dh_p<1..2^16-1>; 285 opaque dh_q<1..2^16-1>; 286 opaque dh_g<1..2^16-1>; 287 opaque dh_Ys<1..2^16-1>; 288 } ServerDHParams; /* Ephemeral DH parameters */ 290 Note that this uses the standard DLP parameter order { p, q, g }, 291 not the erroneous { p, g, q } order from the X9.42 DH 292 specification. 293 o The domain parameters MUST either be compared for equivalence to a 294 set of known-good parameters provided by an appropriate standards 295 body or they MUST be verified as specified in FIPS 186 [9]. 296 Examples of the former may be found in RFC 3526 [26]. 298 Note that while other sources of DH parameters exist, these should be 299 treated with a great deal of caution. For example RFC 5114 [27] 300 provides no source for the values used, leading to suspicions that 301 they may be trapdoored, and RFC 7919 [28] mandates fallback to RSA if 302 the sole DH parameter set for each key size specified in the standard 303 isn't automatically chosen by both client and server. 305 Industry standards bodies may consider restricting domain parameters 306 to only allow known-good values such as those referenced in the above 307 standard, or ones generated by the standards body. This makes 308 checking easier, but has the downside that restricting the choice to 309 a small set of values makes them a more tempting target for well- 310 resourced attackers. In addition it requires that the values be 311 carefully generated, and the generation process be well-documented, 312 to produce a so-called NUMS (Nothing Up My Sleeve) number that avoids 313 any suspicion of it having undesirable hidden properties (the 314 standard mentioned above, RFC 5114 [27], does not contain NUMS 315 values). 317 In any case signing the Client/Server Hello messages and the use of 318 Extended Master Secret makes active attacks that manipulate the 319 domain parameters on the fly far more difficult than they would be 320 for standard TLS. 322 3.3. Miscellaneous 324 TLS-LTS drops the need to send the current time in the random data, 325 which serves no obvious purpose and leaks the client/server's time to 326 attackers: 328 o TLS-LTS implementations SHOULD NOT include the time in the Client/ 329 Server Hello random data. The data SHOULD consist entirely of 330 random bytes. 332 [Note: A proposed downgrade-attack prevention mechanism 333 may make use of these bytes, see section 3.6]. 335 TLS-LTS drops compression and rehandshake, which have led to a number 336 of attacks: 338 o TLS-LTS implementations MUST NOT implement compression or 339 rehandshake. 341 TLS-LTS drops the requirement to generate the Client.random and 342 Server.random using "a secure random number generator", typically the 343 one used to generate encryption keys. The use of a secure/ 344 cryptographic random number generator serves no obvious purpose (all 345 that's required is a unique value), but exposes 224 bits of the 346 cryptographic RNG output to an attacker, allowing them to analyse and 347 potentially attack the RNG, and by extension any crypto keys that it 348 generates: 350 o Implementations SHOULD NOT use the raw output from a 351 cryptographic/secure RNG that's used to generate keying material 352 to generate the Client.random and Server.random values. Instead, 353 they SHOULD employ a mechanism that doesn't directly expose 354 cryptographic RNG output to attackers, for example by using the 355 crypto RNG to seed a hash-based PRF such as the TLS PRF and using 356 the output of that for the values. 358 3.4. Implementation Issues 360 TLS-LTS requires that RSA signature verification be done as encode- 361 then-compare, which fixes all known padding-manipulation issues: 363 o TLS-LTS implementations MUST verify RSA signatures by using 364 encode-then-compare as described in PKCS #1 [10], meaning that 365 they encode the expected signature result and perform a constant- 366 time compare against the recovered signature data. 368 The constant-time compare isn't strictly necessary for security in 369 this case, but it's generally good hygiene and is explicitly required 370 when comparing secret data values: 372 o All operations on crypto- or security-related values SHOULD be 373 performed in a manner that's as timing-independent as possible. 374 For example compares of MAC values such as those used in the 375 Finished message and data packets SHOULD be performed using a 376 constant-time memcmp() or equivalent so as not to leak timing data 377 to an attacker. 379 TLS-LTS recommends that implementations take measures to protect 380 against side-channel attacks: 382 o Implementations SHOULD take steps to protect against timing 383 attacks, for example by using constant-time implementations of 384 algorithms and by using blinding for non-randomised algorithms 385 like RSA. 387 TLS uses a number of crypto mechanisms, some of which are more 388 brittle than others. The ECC algorithms used in are quite vulnerable 389 to faults, with RSA significantly less so. Conversely, the PSK 390 mechanisms are essentially immune to key compromise induced by 391 faults. In terms of bulk encryption mechanisms, AES-GCM is far more 392 vulnerable to faults than AES-CBC: 394 o Implementations SHOULD take steps to protect against fault 395 attacks. One simple countermeasure for the public-key signature 396 mechanisms is to use the public key to verify any signatures 397 generated before they are sent over the wire. Other protection 398 measures include checksumming key data held in memory, 399 particularly where the key is stored over an extended period of 400 time. Implementations intended to be used in harsh environments 401 where faults are expected SHOULD consider the use of TLS-PSK in 402 place of any of the mechanisms using public/private-key 403 authentication, for which key compromise in the presence of faults 404 is unlikely. 406 Authentication mechanisms for protocols run over TLS typically have 407 separate authentication procedures for the tunnelled protocol and the 408 encapsulating TLS session. The leads to an issue known as the 409 channel binding problem in which the tunnelled protocol isn't tied to 410 the encapsulating TLS session and can be manipulated by an attacker 411 once it passes the TLS endpoint. Channel binding ties the 412 cryptographic protection offered by TLS to the protocol that's being 413 run over the TLS tunnel: 415 o Implementations that require authentication for protocols run over 416 TLS SHOULD consider using channel bindings to tie the application- 417 level protocol to the TLS session, specifically the tls_unique 418 binding, which makes use of the contents of the first TLS Finished 419 message sent in an exchange to bind to the tunneled application- 420 level protocol [3]. 422 The original description of the tls_unique binding contains a long 423 note detailing problems that arise due to rehandshake issues and how 424 to deal with them. Since TLS-LTS doesn't allow rehandshakes, these 425 problems don't exist, so no special handling is required. 427 The TLS protocol has historically and somewhat arbitrarily been 428 described as a state machine, which has led to numerous 429 implementation flaws when state transitions weren't very carefully 430 considered and enforced [20]. A safer and more logical means of 431 representing the protocol is as a ladder diagram, which hardcodes the 432 transitions into the diagram and removes the need to juggle a large 433 amount of state: 435 o Implementations SHOULD consider representing/implementing the 436 protocol as a ladder diagram rather than a state machine, since 437 the state-diagram form has led to numerous implementation errors 438 in the past which are avoided through the use of the ladder 439 diagram form. 441 TLS-LTS mandates the use of cipher suites that provide so-called 442 Perfect Forward Secrecy (PFS), in which an attacker can't record 443 sessions and decrypt them at a later date. The PFS property is 444 however impacted by the TLS session cache and session tickets, which 445 allow an attacker to decrypt old sessions. The session cache is 446 relatively short-term and only allows decryption while a session is 447 held in the cache, but the use of long-term keys in combination with 448 session tickets means that an attacker can decrypt any session used 449 with that key, defeating PFS: 451 o Implementations SHOULD consider the impact of using session caches 452 and session tickets on PFS. Security issues in this area can be 453 mitigated by using short session cache expiry times, and avoiding 454 session tickets or changing the key used to encrypt them 455 periodically. 457 Another form of cacheing that can affect security is the reuse of the 458 supposedly-ephemeral DH value y = g^x mod p or its elliptic curve 459 equivalent. Instead of computing a fresh value for each session, 460 some servers for performance reasons compute the y value once and 461 then reuse it across multiple TLS sessions. If this is done then an 462 attacker can compute the discrete log value from one TLS session and 463 reuse it to attack later sessions: 465 o Implementations SHOULD consider the impact of reusing the DH y = 466 g^x mod p value across multiple TLS sessions, and avoid this reuse 467 if possible. Where the reuse of y is unavoidable, it SHOULD be 468 refreshed as often as is feasible. One way to do this is to 469 compute it as a background task so that a fresh value is available 470 when required. 472 TLS-LTS protects its handshake by including cryptographic integrity 473 checks of preceding messages in subsequent messages, defeating 474 attacks that build on the ability to manipulate handshake messages to 475 compromise security. What's authenticated at various stages is a log 476 of preceding messages in the exchange. The simplest way to implement 477 this, if the underlying API supports it, is to keep a running hash of 478 all messages (which will be required for the final Finished 479 computation) and peel off a copy of the current hash state to 480 generate the hash value required at various stages during the 481 handshake. If only the traditional { Begin, [ Update, Update, ... ], 482 Final } hash API interface is available then several parallel chains 483 of hashing will need to be run in order to terminate the hashing at 484 different points during the handshake. 486 Cryptographic protocol implementations rely critically on the 487 implementation performing extensive checking of all crypto operations 488 to ensure that problems are detected and caught. Testing for the 489 failure of these checks is rarely performed in implementations and 490 test suites, and the problem is not picked up by normal testing. To 491 deal with this issue, this specification recommends that 492 implementations test their cryptographic mechanisms to ensure that 493 crypto failures are detected and caught: 495 o Implementations SHOULD apply fault-injection testing to ensure 496 that cryptographic failures are correctly caught. At a minimum, 497 test suites SHOULD be capable of inducing faults in the 498 client_random/server_random, the ServerDHParams/ServerECDHParams 499 in the ServerKeyExchange, the signature value for the server key, 500 the MAC value in the finished message, and the IV, payload data, 501 and MAC values for messages, and the implementation MUST be able 502 to detect these faults. 504 One way to induce such a fault is to flip a bit in the appropriate 505 data value in a location where the problem must be detected by 506 cryptographic means, for example in the binary payload data rather 507 than in an identifier or length field where it would be picked up 508 as a decoding error. 510 o If certificate-based authentication is used, implementations 511 SHOULD apply fault-injection testing to ensure that cryptographic 512 failures in the certificate processing are correctly caught. At a 513 minimum, test suites SHOULD be capable of inducing faults in the 514 signed certificate content and the certificate signature data, and 515 the implementation MUST be able to detect these faults. 517 PKI provides near-unlimited scope for further checking, 518 implementations MAY apply additional testing as required. 520 o If PSK-based authentication is used, implementations SHOULD apply 521 fault-injection testing to ensure that failures in the PSK 522 authentication are correctly caught. At a minimum, test suites 523 SHOULD be capable of inducing faults in the psk_identity and the 524 psk, and the implementation MUST be able to detect these faults. 526 3.5. Use of TLS Extensions 528 TLS-LTS is inspired by Grigg's Law that "there is only one mode and 529 that is secure". Because it mandates the use of known-good 530 mechanisms, much of the signalling and negotiation that's required in 531 standard TLS to reach the same state becomes redundant. In 532 particular, TLS-LTS removes the need to use the following extensions: 534 o The signature_algorithms extension, since the use of SHA-256 with 535 RSA or ECDSA is implicit in TLS-LTS. 537 o The elliptic_curves and ec_point_formats extensions, since the use 538 of P256 with uncompressed points is implicit in TLS-LTS. 540 o The universally-ignored requirement that all certificates provided 541 by the server must be signed by the algorithm(s) specified in the 542 signature_algorithms extension is removed both implicitly by not 543 sending the extension and explicitly by removing this requirement. 545 o The encrypt_then_mac extension, since the use of encrypt-then-MAC 546 is implicit in TLS-LTS. 548 o The extended_master_secret extension, since the use of extended 549 Master Secret is implicit in TLS-LTS. 551 TLS-LTS implementations that wish to communicate only with other TLS- 552 LTS implementations MAY omit these extensions, with the presence of 553 tls_lts implying signature_algorithms = RSA/ECDSA + SHA-256, 554 elliptic_curves = P256, ec_point_formats = uncompressed, 555 encrypt_then_mac = TRUE, and extended_master_secret = TRUE. 556 Implementations that wish to communicate with legacy implementations 557 and wish to use the capabilities described by the extensions outside 558 of TLS-LTS MUST include these extensions in their Client Hello. 560 Conversely, although all of the above extensions are implied by TLS- 561 LTS, if a client requests TLS-LTS in its Client Hello then it doesn't 562 expect to see them returned in the Server Hello if TLS-LTS is 563 indicated. The handling of extensions during the Client/Server Hello 564 exchange is therefore as follows: 566 +-------------------------+--------------------+--------------------+ 567 | Client Hello | Server Chooses | Server Hello | 568 +-------------------------+--------------------+--------------------+ 569 | TLS-LTS | TLS-LTS | TLS-LTS | 570 | | | | 571 | TLS-LTS, | TLS-LTS | TLS-LTS | 572 | EMS/EncThenMAC/... | | | 573 | | | | 574 | TLS-LTS, | EMS/EncThenMAC/... | EMS/EncThenMAC/... | 575 | EMS/EncThenMAC/... | | | 576 +-------------------------+--------------------+--------------------+ 578 Table 1: Use of TLS-LTS Extensions 580 TLS-LTS capabilities are indicated purely by the presence of the 581 tls_lts extension, not the plethora of other extensions that it's 582 comprised of. This allows an implementation that needs to be 583 backwards-compatible with legacy implementations to specify 584 individual options for use with non-TLS-LTS implementations via a 585 range of extensions, and specify the use of TLS-LTS via the tls_lts 586 extension. 588 3.6. Downgrade Attack Prevention 590 The use of the TLS-LTS improvements relies on an attacker not being 591 able to delete the TLS-LTS extension from the Client/Server Hello 592 messages. This is achieved through the SCSV [7] signalling 593 mechanism. 595 [If SCSV is used then insert required boilerplate here, however this 596 will also require banning weak cipher suites like export ones, which 597 is a bit interesting in that it'll required banning something that in 598 theory has already been extinct for 15 years. A better option is to 599 refer to Karthikeyan Bhargavan's rather clever idea on anti-downgrade 600 signalling, which is a more reliable mechanism than SCSV]. 602 3.7. Rationale 604 This section addresses the question of why this document specifies a 605 long-term support profile for TLS 1.2 rather than going to TLS 1.3. 606 The reason for this is twofold. Firstly, we know that TLS, which has 607 become more or less the universal substrate for secure communications 608 over the Internet, has extremely long deployment times. Much of this 609 information is anecdotal (although there are a large number of these 610 anecdotes), however one survey carried out in 2015 and 2016 611 illustrates the scope of the problem. This study found that the most 612 frequently-encountered protocol (in terms of use in observed Internet 613 connections) was the fifteen-year-old TLS 1.0, with the next most 614 common, TLS 1.2, lagging well behind [25]. This was on the public 615 Internet, in the non-public arena (where much of the anecdotal 616 evidence comes from, since it's not possible to perform a public 617 scan) the most common protocol appears to be TLS 1.0, with 618 significant numbers of systems still using the twenty-year-old SSLv3. 620 Given that TLS 1.3 is almost a completely new protocol compared to 621 the incremental changes from SSLv3 to TLS 1.2, and that the most 622 widely-encountered protocol version from that branch is more than 623 fifteen years old, it's likely that TLS 1.3 deployment outside of 624 constantly-updated web browsers may take one to two decades, or may 625 never happen at all given that a move to TLS 1.2 is an incremental 626 change from TLS 1.0 while TLS 1.3 requires the implementation of a 627 new protocol. This document takes the position that if a protocol 628 from the TLS 1.0 - 1.2 branch will remain in use for decades to come, 629 it should be the best form of TLS 1.2 available. 631 The second reason why this document exists has already been mentioned 632 above, that while TLS 1.0 - 1.2 are all from the same fairly similar 633 family, TLS 1.3 is an almost entirely new protocol. As such, it 634 rolls back the 20 years of experience that we have with all the 635 things that can go wrong in TLS and starts again from scratch with a 636 new protocol based on bleeding-edge/experimental ideas, mechanisms, 637 and algorithms. When SSLv3 was introduced, it used ideas that were 638 10-20 years old (DH, RSA, DES, and so on were all long-established 639 algorithms, only SHA-1 was relatively new). These were mature 640 algorithms with large amounts of research published on them, and yet 641 we're still fixing issues with them 20 years later (the DH algorithm 642 was published in 1976, SSLv3 dates from 1996, and the latest DH 643 issue, Logjam, dates from 2015). With TLS 1.3 we currently have zero 644 implementation and deployment experience, which means that we're 645 likely to have another 10-20 years of patching holes and fixing 646 protocol and implementation problems ahead of us. 648 It's for this reason that this specification uses the decades of 649 experience we have with SSL and TLS and the huge deployed base of TLS 650 1.0 - 1.2 implementations to update TLS 1.2 into a known-good form 651 that leverages about 15 years of analysis and 20 years of 652 implementation experience, rather than betting on what's almost an 653 entirely new protocol based on experimental ideas, mechanisms, and 654 algorithms, and hoping that it can be deployed in less than a decade- 655 or multi-decade time frame. The intent is to create a long-term 656 stable protocol specification that can be deployed once as a minor 657 update to existing TLS implementations, not deployed as a new from- 658 scratch implementation and then patched, updated, and fixed 659 constantly for the lifetime of the equipment that it's used with. 661 4. Security Considerations 663 This document defines a minimal, known-good subset of TLS 1.2 that 664 attempts to address all known weaknesses in the protocol, mostly by 665 simply removing known-insecure mechanisms but also by updating the 666 ones that remain to take advantage of many years of security research 667 and implementation experience. As an example of its efficacy, 668 several attacks on standard TLS that emerged after this document was 669 first published were countered by the mechanisms specified here, with 670 no updates or changes to TLS-LTS implementations being necessary to 671 deal with them. 673 4.1. Security Properties Provided by TLS-LTS 675 If implemented correctly, TLS will provide confidentiality and 676 integrity protection of traffic, and guarantees liveness of the 677 communications. In some circumstances it also provides 678 authentication, see below. Apart from that, it provides no other 679 guarantees. 681 4.2. Security Properties Not Provided by TLS-LTS 683 TLS does not in general protect against spoofing (most commonly 684 encountered on the web as phishing). The one exception is when one 685 of the PSK mechanisms, which provides mutual cryptographic 686 authentication of client and server, is used. PKI, a mechanism 687 outside of TLS, is expected to provide protection against spoofing, 688 but in practice rarely does so. 690 Unless implemented very carefully, TLS does not provide strong 691 protection against side-channel attacks. While this document 692 specifies countermeasures against timing and oracle side-channels 693 that should be employed, these are very difficult to get right and 694 not always effective. 696 TLS provides no real protection against traffic analysis. While the 697 protocol specification contains provisions for message padding, this 698 has little effect on attackers in practice. 700 In the presence of implementation flaws (bugs) or hardware or 701 software errors, some TLS mechanisms may fail catastrophically. AES- 702 GCM is fatally vulnerable to nonce reuse or repeated counter/IV 703 values. AES-CBC in contrast can be arbitrarily abused, for example 704 by setting the IV to the constant value zero, with at most a slight 705 degradation in security (reduction to ECB mode) rather than a 706 complete loss of security. 708 TLS provides no availability guarantees. In fact since it increases 709 susceptibility to failures, either genuine or artificially-induced 710 (for example due to an expired certificate that's otherwise fully 711 valid), it reduces overall availability. 713 TLS provides no guarantees of non-repudiation, access control, or 714 authorisation. These services must be provided by external 715 mechanisms. 717 In short, TLS provides confidentiality (if the crypto is implemented 718 properly and steps are taken to protect against faults and failures), 719 integrity protection, and in some limited cases authentication. It 720 does not provide any other service. If further security services are 721 required, these must be provided through additional, external 722 mechanisms. 724 TLS is a cryptographic protocol, not security pixie dust. Before 725 deciding to employ it, you should evaluate whether it actually 726 provides the security services that you think it does. 728 5. IANA Considerations 730 IANA has added the extension code point TBD (0xTBD) for the tls_lts 731 extension to the TLS ExtensionType values registry as specified in 732 TLS [2]. 734 6. Acknowledgements 736 The author would like to thank contributors from various embedded 737 system vendors for their feedback on this document. 739 7. References 741 7.1. Normative References 743 [1] Bradner, S., "Key words for use in RFCs to Indicate 744 Requirement Levels", BCP 14, RFC 2119, March 1997. 746 [2] Dierks, T. and E. Rescorla, "The Transport Layer Security 747 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 749 [3] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 750 for TLS", RFC 5929, July 2010. 752 [4] Eastlake 3rd, D., "Transport Layer Security (TLS) 753 Extensions", RFC 6066, January 2011. 755 [5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 756 Security Version 1.2", RFC 6347, January 2012. 758 [6] Gutmann, P., "Encrypt-then-MAC for Transport Layer 759 Security (TLS) and Datagram Transport Layer Security 760 (DTLS)", RFC 7366, September 2014. 762 [7] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 763 Suite Value (SCSV) for Preventing Protocol Downgrade 764 Attacks", RFC 7507, April 2015. 766 [8] Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 767 A., and M. Ray, "Transport Layer Security (TLS) Session 768 Hash and Extended Master Secret Extension", RFC 7627, 769 September 2015. 771 [9] "Digital Signature Standard (DSS)", FIPS 186, July 2013. 773 [10] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 774 Standards (PKCS) #1: RSA Cryptography Specifications 775 Version 2.1", RFC 3447, February 2003. 777 7.2. Informative References 779 [11] Bhargavan, K., Fournet, C., Kohlweiss, M., Pironti, A., 780 Strub, P., and S. Zanella-Beguelin, "Proving the TLS 781 handshake secure (as is)", Springer-Verlag LNCS 8617, 782 August 2014. 784 [12] Brzuska, C., Fischlin, M., Smart, N., Warinschi, B., and 785 S. Williams, "Less is more: relaxed yet compatible 786 security notions for key exchange", IACR ePrint 787 archive 2012/242, April 2012. 789 [13] Dowling, B. and D. Stebila, "Modelling ciphersuite and 790 version negotiation in the TLS protocol", Springer-Verlag 791 LNCS 9144, June 2015. 793 [14] Firing, T., "Analysis of the Transport Layer Security 794 protocol", June 2010. 796 [15] Gajek, S., Manulis, M., Pereira, O., Sadeghi, A., and J. 797 Schwenk, "Universally Composable Security Analysis of 798 TLS", Springer-Verlag LNCS 5324, November 2008. 800 [16] Jager, T., Kohlar, F., Schaege, S., and J. Schwenk, "On 801 the security of TLS-DHE in the standard model", Springer- 802 Verlag LNCS 7417, August 2012. 804 [17] Shrimpton, T., "A long answer to the simple question, "Is 805 TLS provably secure?"", Workshop on Theory and Practice in 806 Cryptography 2012, January 2012. 808 [18] Giesen, F., Kohlar, F., and D. Stebila, "On the security 809 of TLS renegotiation", ACM CCS 2013, November 2013. 811 [19] Meyer, C. and J. Schwenk, "Lessons Learned From Previous 812 SSL/TLS Attacks - A Brief Chronology Of Attacks And 813 Weaknesses", Cryptology ePrint Archive 2013/049, January 814 2013. 816 [20] Krawczyk, H., Paterson, K., and H. Wee, "On the security 817 of the TLS protocol", Springer-Verlag LNCS 8042, August 818 2013. 820 [21] Wee, H., "On the Security of SSL/TLS", Workshop on Theory 821 and Practice in Cryptography 2014, January 2014. 823 [22] Stebila, D., "Provable security of advanced properties of 824 TLS and SSH", Workshop on Theory and Practice in 825 Cryptography 2014, January 2014. 827 [23] Beurdouche, B., Bhargavan, K., Delignat-Lavaud, A., 828 Fournet, C., Kohlweiss, M., Pironti, A., Strub, P., and J. 829 Zinzindohoue, "A Messy State of the Union: Taming the 830 Composite State Machines of TLS", IEEE Symposium on 831 Security and Privacy 2015, May 2015. 833 [24] Bhargavan, K. and M. Kohlweiss, "Triple Handshake: Can 834 cryptography, formal methods, and applied security be 835 friends?", Workshop on Theory and Practice in 836 Cryptography 2015, January 2015. 838 [25] Holz, R., Amann, J., Mehani, O., Wachs, M., and M. Kaafar, 839 "TLS in the Wild: An Internet-Wide Analysis of TLS-Based 840 Protocols for Electronic Communication", Network and 841 Distributed System Security Symposium 2016, February 2016. 843 [26] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 844 Diffie-Hellman groups for Internet Key Exchange (IKE)", 845 RFC 3526, May 2003. 847 [27] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 848 Groups for Use with IETF Standards", RFC 5114, January 849 2008. 851 [28] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 852 Ephemeral Parameters for Transport Layer Security (TLS)", 853 RFC 7919, August 2016. 855 Author's Address 857 Peter Gutmann 858 University of Auckland 859 Department of Computer Science 860 University of Auckland 861 New Zealand 863 Email: pgut001@cs.auckland.ac.nz