idnits 2.17.1 draft-gutmann-tls-lts-08.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 (April 24, 2017) is 2557 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) ** 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 (~~), 1 warning (==), 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 April 24, 2017 5 Expires: October 26, 2017 7 TLS 1.2 Update for Long-term Support 8 draft-gutmann-tls-lts-08 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 October 26, 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 . . . . . . . . . . . . . . . . . . . . . 7 62 3.3. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 8 63 3.4. Implementation Issues . . . . . . . . . . . . . . . . . . 8 64 3.5. Use of TLS Extensions . . . . . . . . . . . . . . . . . . 12 65 3.6. Downgrade Attack Prevention . . . . . . . . . . . . . . . 13 66 3.7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 14 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . 17 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 [27], 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] [25] 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, as well as guidance on 102 implementing this feature set in a sound manner. This is intended 103 for use in systems that need to run in a fixed configuration for a 104 long period of time after they're deployed, with little or no ability 105 to roll out patches every month or two when the next attack on TLS is 106 published. 108 Unlike the full TLS 1.2, TLS-LTS is not meant to be all things to all 109 people. It represents a fixed, safe solution that's appropriate for 110 users who require a simple, secure, and long-term stable means of 111 getting data from A to B. This represents the majority of the non- 112 browser uses of TLS, particularly for embedded systems that are most 113 in need of a long-term stable protocol definition. 115 [Note: There is currently a TLS 1.2 LTS test server running 116 at https://82.94.251.205:8443. This uses the extension 117 value 26 until a value is permanently assigned for LTS 118 use. To connect, your implementation should accept 119 whatever certificate is presented by the server or use PSK 120 with name = "plc", password = "test". For embedded 121 systems testing, note that the this is a conventional web 122 server, not an IED/RTU/PLC, that talks HTTP and not DNP3 or 123 ICCP/TASE.2, so you'll get an error if you try and connect 124 with a PLC control centre that expects one of those 125 protocols]. 127 1.1. Conventions Used in This Document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [1]. 133 2. TLS-LTS Negotiation 135 The use of TLS-LTS is negotiated via TLS/DTLS extensions as defined 136 in TLS Extensions [4]. On connecting, the client includes the 137 tls_lts extension in its Client Hello if it wishes to use TLS-LTS. 138 If the server is capable of meeting this requirement, it responds 139 with a tls_lts extension in its Server Hello. The "extension_type" 140 value for this extension MUST be 26 (0x1A, see IANA Considerations 141 below) and the "extension_data" field of this extension is empty. 142 The client and server MUST NOT use TLS-LTS unless both sides have 143 successfully exchanged tls_lts extensions. 145 Note that the TLS-LTS extension applies to TLS 1.2, not to any 146 earlier version of TLS. If a client requests the use of TLS-LTS in 147 its client_hello but the server falls back to TLS 1.1 or earlier, it 148 MUST NOT indicate the use of TLS-LTS in its server_hello. 150 In the case of session resumption, once TLS-LTS has been negotiated 151 implementations MUST retain the use of TLS-LTS across all subsequent 152 resumed sessions. In other words if TLS-LTS is enabled for the 153 current session then the resumed session MUST also use TLS-LTS. If a 154 client or server attempts to resume a TLS-LTS session as a non-TLS- 155 LTS session then the peer MUST abort the handshake. 157 3. TLS-LTS 159 TLS-LTS specifies a few simple restrictions on the huge range of TLS 160 suites, options and parameters to limit the protocol to a known-good 161 subset, as well as making minor corrections to prevent or at least 162 limit various attacks. 164 3.1. Encryption/Authentication 166 TLS-LTS restricts the more or less unlimited TLS 1.2 with its more 167 than three hundred cipher suites, over forty ECC parameter sets, and 168 zoo of supplementary algorithms, parameters, and parameter formats, 169 to just two, one traditional one with DHE + AES-CBC + HMAC-SHA-256 + 170 RSA-SHA-256/PSK and one ECC one with ECDHE-P256 + AES-GCM + HMAC- 171 SHA-256 + ECDSA-P256-SHA-256/PSK with uncompressed points: 173 o TLS-LTS implementations MUST support 174 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, 175 TLS_DHE_PSK_WITH_AES_128_CBC_SHA256, 176 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 177 TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256. For these suites, SHA-256 178 is used in all locations in the protocol where a hash function is 179 required, specifically in the PRF and per-packet MAC calculations 180 (as indicated by the _SHA256 in the suite) and also in the client 181 and server signatures in the CertificateVerify and 182 ServerKeyExchange messages. 184 [Note: There's a gap in the suites with 185 TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 missing, there's 186 currently a draft in progress to fill the gap, 187 draft-mattsson-tls-ecdhe-psk-aead, which can be used to 188 replace the placeholder TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256]. 190 TLS-LTS only permits encrypt-then-MAC, not MAC-then-encrypt, fixing 191 20 years of attacks on this mechanism: 193 o TLS-LTS implementations MUST implement encrypt-then-MAC [6] rather 194 than the earlier MAC-then-encrypt. 196 TLS-LTS adds a hash of all messages leading up to the calculation of 197 the master secret into the master secret to protect against the use 198 of manipulated handshake parameters: 200 o TLS-LTS implementations MUST implement extended master secret [8] 201 to protect handshake and crypto parameters. 203 In several locations TLS modifies or truncates the output of 204 cryptographic operations so that the original security guarantees 205 associated with them may no longer be valid. TLS-LTS utilises the 206 full cryptographic parameters rather than partial, truncated, or 207 otherwise modified forms. In particular, TLS-LTS drops the MAC 208 truncation of the Finished message contents and uses the full 209 elliptic curve point Q output from the ECDH key agreement mechanism 210 rather than the point's x coordinate by itself: 212 o The length of verify_data (verify_data_length) in the Finished 213 message MUST be equal to the length of the output of the hash 214 function used for the PRF. For the mandatory TLS-LTS cipher 215 suites this hash is always SHA-256, so the value of 216 verify_data_length will be 32 bytes. For other suites, the size 217 depends on the hash algorithm associated with the suite. For 218 example for SHA-512 it would be 64 bytes. 220 o When ECDH is used to establish the premaster secret, the premaster 221 secret value is the full elliptic curve point Q as output from the 222 ECDH key agreement mechanism rather than the x coordinate of the 223 point Q by itself. In other words for the uncompressed point 224 format used in TLS-LTS, the premaster secret would be 04 || qx || 225 qy rather than qx by itself. 227 TLS-LTS signs a hash of the client and server hello messages for the 228 ServerKeyExchange rather than signing just the client and server 229 nonces, avoiding various attacks that build on the fact that standard 230 TLS doesn't authenticate previously-exchanged parameters when the 231 ServerKeyExchange message is sent: 233 o When generating the ServerKeyExchange signature, the signed_params 234 value is updated to replace the client_random and server_random 235 with a hash of the full Client Hello and Server Hello using the 236 hash algorithm for the chosen cipher suite. In other words the 237 value being signed is changed from: 239 digitally-signed struct { 240 opaque client_random[32]; 241 opaque server_random[32]; 242 ServerDHParams params; 243 } signed_params; 245 to: 247 digitally-signed struct { 248 opaque client_server_hello_hash; 249 ServerDHParams params; 250 } signed_params; 252 For the mandatory TLS-LTS cipher suites the hash algorithm is 253 always SHA-256, so the length of the client_server_hello_hash is 254 32 bytes. For other suites, the size depends on the hash 255 algorithm associated with the suite. For example for SHA-512 it 256 would be 64 bytes. 258 (In terms of side-channel attack prevention, it would be preferable 259 to include a non-public quantity into the data being signed since 260 this reduces the scope of attack from a passive to an active one, 261 with the attacker needing to initiate their own handshakes in order 262 to carry out their attack. However no shared secret value has been 263 established at this point so only public data can be signed). 265 The choice of key sizes is something that will never get any 266 consensus because there are so many different worldviews involved. 267 TLS-LTS makes only general recommendations on best practices and 268 leaves the choice of which key sizes are appropriate to implementers 269 and policy makers: 271 o Implementations SHOULD choose public-key algorithm key sizes that 272 are appropriate for the situation, weighted by the value of the 273 information being protected, the probability of attack and 274 capabilities of the attacker(s), any relevant security policies, 275 and the ability of the system running the TLS implementation to 276 deal with the computational load of large keys. For example a 277 SCADA system being used to switch a ventilator on and off doesn't 278 require anywhere near the keysize-based security of a system used 279 to transfer classified data. 281 One way to avoid having to use very large public keys is to switch 282 the keys periodically. For example for DH keys this can be done by 283 regenerating DH parameters in a background thread and rolling them 284 over from time to time. If this isn't possible, an alternative 285 option is to pre-generate a selection of DH parameters and choose one 286 set at random for each new handshake, or again roll them over from 287 time to time from the pre-generated selection, so that an attacker 288 has to attack multiple sets of parameters rather than just one. 290 3.2. Message Formats 292 TLS-LTS sends the full set of DH parameters, X9.42/FIPS 186 style, 293 not p and g only, PKCS #3 style. This allows verification of the DH 294 parameters, which the current format doesn't allow: 296 o TLS-LTS implementations MUST send the DH domain parameters as { p, 297 q, g } rather than { p, g }. This makes the ServerDHParams field: 299 struct { 300 opaque dh_p<1..2^16-1>; 301 opaque dh_q<1..2^16-1>; 302 opaque dh_g<1..2^16-1>; 303 opaque dh_Ys<1..2^16-1>; 304 } ServerDHParams; /* Ephemeral DH parameters */ 306 Note that this uses the standard DLP parameter order { p, q, g }, 307 not the erroneous { p, g, q } order from the X9.42 DH 308 specification. 309 o The domain parameters MUST either be compared for equivalence to a 310 set of known-good parameters provided by an appropriate standards 311 body or they MUST be verified as specified in FIPS 186 [9]. 312 Examples of the former may be found in RFC 3526 [30]. 314 Note that while other sources of DH parameters exist, these should be 315 treated with a great deal of caution. For example RFC 5114 [31] 316 provides no source for the values used, leading to suspicions that 317 they may be trapdoored, and RFC 7919 [32] mandates fallback to RSA if 318 the sole DH parameter set for each key size specified in the standard 319 isn't automatically chosen by both client and server. 321 Industry standards bodies may consider restricting domain parameters 322 to only allow known-good values such as those referenced in the above 323 standard, or ones generated by the standards body. This makes 324 checking easier, but has the downside that restricting the choice to 325 a small set of values makes them a more tempting target for well- 326 resourced attackers. In addition it requires that the values be 327 carefully generated, and the generation process be well-documented, 328 to produce a so-called NUMS (Nothing Up My Sleeve) number that avoids 329 any suspicion of it having undesirable hidden properties (the 330 standard mentioned above, RFC 5114 [31], does not contain NUMS 331 values). 333 In any case signing the Client/Server Hello messages and the use of 334 Extended Master Secret makes active attacks that manipulate the 335 domain parameters on the fly far more difficult than they would be 336 for standard TLS. 338 3.3. Miscellaneous 340 TLS-LTS drops the need to send the current time in the random data, 341 which serves no obvious purpose and leaks the client/server's time to 342 attackers: 344 o TLS-LTS implementations SHOULD NOT include the time in the Client/ 345 Server Hello random data. The data SHOULD consist entirely of 346 random bytes. 348 [Note: A proposed downgrade-attack prevention mechanism 349 may make use of these bytes, see section 3.6]. 351 TLS-LTS drops compression and rehandshake, which have led to a number 352 of attacks: 354 o TLS-LTS implementations MUST NOT implement compression or 355 rehandshake. 357 TLS-LTS drops the requirement to generate the Client.random and 358 Server.random using "a secure random number generator", typically the 359 one used to generate encryption keys. The use of a secure/ 360 cryptographic random number generator serves no obvious purpose (all 361 that's required is a unique value), but exposes 224 bits of the 362 cryptographic RNG output to an attacker, allowing them to analyse and 363 potentially attack the RNG, and by extension any crypto keys that it 364 generates: 366 o Implementations SHOULD NOT use the raw output from a 367 cryptographic/secure RNG that's used to generate keying material 368 to generate the Client.random and Server.random values. Instead, 369 they SHOULD employ a mechanism that doesn't directly expose 370 cryptographic RNG output to attackers, for example by using the 371 crypto RNG to seed a hash-based PRF such as the TLS PRF and using 372 the output of that for the values. 374 3.4. Implementation Issues 376 TLS-LTS requires that RSA signature verification be done as encode- 377 then-compare, which fixes all known padding-manipulation issues: 379 o TLS-LTS implementations MUST verify RSA signatures by using 380 encode-then-compare as described in PKCS #1 [10], meaning that 381 they encode the expected signature result and perform a constant- 382 time compare against the recovered signature data. 384 The constant-time compare isn't strictly necessary for security in 385 this case, but it's generally good hygiene and is explicitly required 386 when comparing secret data values: 388 o All operations on crypto- or security-related values SHOULD be 389 performed in a manner that's as timing-independent as possible. 390 For example compares of MAC values such as those used in the 391 Finished message and data packets SHOULD be performed using a 392 constant-time memcmp() or equivalent so as not to leak timing data 393 to an attacker. 395 TLS-LTS recommends that implementations take measures to protect 396 against side-channel attacks: 398 o Implementations SHOULD take steps to protect against timing 399 attacks, for example by using constant-time implementations of 400 algorithms and by using blinding for non-randomised algorithms 401 like RSA. 403 TLS uses a number of crypto mechanisms, some of which are more 404 brittle than others. The ECC algorithms used in are quite vulnerable 405 to faults, with RSA significantly less so. Conversely, the PSK 406 mechanisms are essentially immune to key compromise induced by 407 faults. In terms of bulk encryption mechanisms, AES-GCM is far more 408 vulnerable to faults than AES-CBC: 410 o Implementations SHOULD take steps to protect against fault 411 attacks. One simple countermeasure for the public-key signature 412 mechanisms is to use the public key to verify any signatures 413 generated before they are sent over the wire. Other protection 414 measures include checksumming key data held in memory, 415 particularly where the key is stored over an extended period of 416 time. Implementations intended to be used in harsh environments 417 where faults are expected SHOULD consider the use of TLS-PSK in 418 place of any of the mechanisms using public/private-key 419 authentication, for which key compromise in the presence of faults 420 is unlikely. 422 Authentication mechanisms for protocols run over TLS typically have 423 separate authentication procedures for the tunnelled protocol and the 424 encapsulating TLS session. The leads to an issue known as the 425 channel binding problem in which the tunnelled protocol isn't tied to 426 the encapsulating TLS session and can be manipulated by an attacker 427 once it passes the TLS endpoint. Channel binding ties the 428 cryptographic protection offered by TLS to the protocol that's being 429 run over the TLS tunnel: 431 o Implementations that require authentication for protocols run over 432 TLS SHOULD consider using channel bindings to tie the application- 433 level protocol to the TLS session, specifically the tls_unique 434 binding, which makes use of the contents of the first TLS Finished 435 message sent in an exchange to bind to the tunneled application- 436 level protocol [3]. 438 The original description of the tls_unique binding contains a long 439 note detailing problems that arise due to rehandshake issues and how 440 to deal with them. Since TLS-LTS doesn't allow rehandshakes, these 441 problems don't exist, so no special handling is required. 443 The TLS protocol has historically and somewhat arbitrarily been 444 described as a state machine, which has led to numerous 445 implementation flaws when state transitions weren't very carefully 446 considered and enforced [20][23] [25] [26]. A safer and more logical 447 means of representing the protocol is as a ladder diagram, which 448 hardcodes the transitions into the diagram and removes the need to 449 juggle a large amount of state: 451 o Implementations SHOULD consider representing/implementing the 452 protocol as a ladder diagram rather than a state machine, since 453 the state-diagram form has led to numerous implementation errors 454 in the past which are avoided through the use of the ladder 455 diagram form. 457 TLS-LTS mandates the use of cipher suites that provide so-called 458 Perfect Forward Secrecy (PFS), in which an attacker can't record 459 sessions and decrypt them at a later date. The PFS property is 460 however impacted by the TLS session cache and session tickets, which 461 allow an attacker to decrypt old sessions. The session cache is 462 relatively short-term and only allows decryption while a session is 463 held in the cache, but the use of long-term keys in combination with 464 session tickets means that an attacker can decrypt any session used 465 with that key, defeating PFS: 467 o Implementations SHOULD consider the impact of using session caches 468 and session tickets on PFS. Security issues in this area can be 469 mitigated by using short session cache expiry times, and avoiding 470 session tickets or changing the key used to encrypt them 471 periodically. 473 Another form of cacheing that can affect security is the reuse of the 474 supposedly-ephemeral DH value y = g^x mod p or its elliptic curve 475 equivalent. Instead of computing a fresh value for each session, 476 some servers for performance reasons compute the y value once and 477 then reuse it across multiple TLS sessions. If this is done then an 478 attacker can compute the discrete log value from one TLS session and 479 reuse it to attack later sessions: 481 o Implementations SHOULD consider the impact of reusing the DH y = 482 g^x mod p value across multiple TLS sessions, and avoid this reuse 483 if possible. Where the reuse of y is unavoidable, it SHOULD be 484 refreshed as often as is feasible. One way to do this is to 485 compute it as a background task so that a fresh value is available 486 when required. 488 TLS-LTS protects its handshake by including cryptographic integrity 489 checks of preceding messages in subsequent messages, defeating 490 attacks that build on the ability to manipulate handshake messages to 491 compromise security. What's authenticated at various stages is a log 492 of preceding messages in the exchange. The simplest way to implement 493 this, if the underlying API supports it, is to keep a running hash of 494 all messages (which will be required for the final Finished 495 computation) and peel off a copy of the current hash state to 496 generate the hash value required at various stages during the 497 handshake. If only the traditional { Begin, [ Update, Update, ... ], 498 Final } hash API interface is available then several parallel chains 499 of hashing will need to be run in order to terminate the hashing at 500 different points during the handshake. 502 Cryptographic protocol implementations rely critically on the 503 implementation performing extensive checking of all crypto operations 504 to ensure that problems are detected and caught. Testing for the 505 failure of these checks is rarely performed in implementations and 506 test suites, and the problem is not picked up by normal testing. To 507 deal with this issue, this specification recommends that 508 implementations test their cryptographic mechanisms to ensure that 509 crypto failures are detected and caught: 511 o Implementations SHOULD apply fault-injection testing to ensure 512 that cryptographic failures are correctly caught. At a minimum, 513 test suites SHOULD be capable of inducing faults in the 514 client_random/server_random, the ServerDHParams/ServerECDHParams 515 in the ServerKeyExchange, the signature value for the server key, 516 the MAC value in the finished message, and the IV, payload data, 517 and MAC values for messages, and the implementation MUST be able 518 to detect these faults. 520 One way to induce such a fault is to flip a bit in the appropriate 521 data value in a location where the problem must be detected by 522 cryptographic means, for example in the binary payload data rather 523 than in an identifier or length field where it would be picked up 524 as a decoding error. 526 o If certificate-based authentication is used, implementations 527 SHOULD apply fault-injection testing to ensure that cryptographic 528 failures in the certificate processing are correctly caught. At a 529 minimum, test suites SHOULD be capable of inducing faults in the 530 signed certificate content and the certificate signature data, and 531 the implementation MUST be able to detect these faults. 533 PKI provides near-unlimited scope for further checking, 534 implementations MAY apply additional testing as required. 536 o If PSK-based authentication is used, implementations SHOULD apply 537 fault-injection testing to ensure that failures in the PSK 538 authentication are correctly caught. At a minimum, test suites 539 SHOULD be capable of inducing faults in the psk_identity and the 540 psk, and the implementation MUST be able to detect these faults. 542 3.5. Use of TLS Extensions 544 TLS-LTS is inspired by Grigg's Law that "there is only one mode and 545 that is secure". Because it mandates the use of known-good 546 mechanisms, much of the signalling and negotiation that's required in 547 standard TLS to reach the same state becomes redundant. In 548 particular, TLS-LTS removes the need to use the following extensions: 550 o The signature_algorithms extension, since the use of SHA-256 with 551 RSA or ECDSA is implicit in TLS-LTS. 553 o The elliptic_curves and ec_point_formats extensions, since the use 554 of P256 with uncompressed points is implicit in TLS-LTS. 556 o The universally-ignored requirement that all certificates provided 557 by the server must be signed by the algorithm(s) specified in the 558 signature_algorithms extension is removed both implicitly by not 559 sending the extension and explicitly by removing this requirement. 561 o The encrypt_then_mac extension, since the use of encrypt-then-MAC 562 is implicit in TLS-LTS. 564 o The extended_master_secret extension, since the use of extended 565 Master Secret is implicit in TLS-LTS. 567 TLS-LTS implementations that wish to communicate only with other TLS- 568 LTS implementations MAY omit these extensions, with the presence of 569 tls_lts implying signature_algorithms = RSA/ECDSA + SHA-256, 570 elliptic_curves = P256, ec_point_formats = uncompressed, 571 encrypt_then_mac = TRUE, and extended_master_secret = TRUE. 572 Implementations that wish to communicate with legacy implementations 573 and wish to use the capabilities described by the extensions outside 574 of TLS-LTS MUST include these extensions in their Client Hello. 576 Conversely, although all of the above extensions are implied by TLS- 577 LTS, if a client requests TLS-LTS in its Client Hello then it doesn't 578 expect to see them returned in the Server Hello if TLS-LTS is 579 indicated. The handling of extensions during the Client/Server Hello 580 exchange is therefore as follows: 582 +-------------------------+--------------------+--------------------+ 583 | Client Hello | Server Chooses | Server Hello | 584 +-------------------------+--------------------+--------------------+ 585 | TLS-LTS | TLS-LTS | TLS-LTS | 586 | | | | 587 | TLS-LTS, | TLS-LTS | TLS-LTS | 588 | EMS/EncThenMAC/... | | | 589 | | | | 590 | TLS-LTS, | EMS/EncThenMAC/... | EMS/EncThenMAC/... | 591 | EMS/EncThenMAC/... | | | 592 +-------------------------+--------------------+--------------------+ 594 Table 1: Use of TLS-LTS Extensions 596 TLS-LTS capabilities are indicated purely by the presence of the 597 tls_lts extension, not the plethora of other extensions that it's 598 comprised of. This allows an implementation that needs to be 599 backwards-compatible with legacy implementations to specify 600 individual options for use with non-TLS-LTS implementations via a 601 range of extensions, and specify the use of TLS-LTS via the tls_lts 602 extension. 604 3.6. Downgrade Attack Prevention 606 The use of the TLS-LTS improvements relies on an attacker not being 607 able to delete the TLS-LTS extension from the Client/Server Hello 608 messages. This is achieved through the SCSV [7] signalling 609 mechanism. 611 [If SCSV is used then insert required boilerplate here, however this 612 will also require banning weak cipher suites like export ones, which 613 is a bit interesting in that it'll required banning something that in 614 theory has already been extinct for 15 years. A better option is to 615 refer to Karthikeyan Bhargavan's rather clever idea on anti-downgrade 616 signalling, which is a more reliable mechanism than SCSV]. 618 3.7. Rationale 620 This section addresses the question of why this document specifies a 621 long-term support profile for TLS 1.2 rather than going to TLS 1.3. 622 The reason for this is twofold. Firstly, we know that TLS, which has 623 become more or less the universal substrate for secure communications 624 over the Internet, has extremely long deployment times. Much of this 625 information is anecdotal (although there are a large number of these 626 anecdotes), however one survey carried out in 2015 and 2016 627 illustrates the scope of the problem. This study found that the most 628 frequently-encountered protocol (in terms of use in observed Internet 629 connections) was the fifteen-year-old TLS 1.0, with the next most 630 common, TLS 1.2, lagging well behind [27]. This was on the public 631 Internet, in the non-public arena (where much of the anecdotal 632 evidence comes from, since it's not possible to perform a public 633 scan) the most common protocol appears to be TLS 1.0 (which includes 634 it being hardcoded into specifications like the widely-used DPWS [28] 635 and IEC 62351 [29]), with significant numbers of systems still using 636 the twenty-year-old SSLv3. 638 Given that TLS 1.3 is almost a completely new protocol compared to 639 the incremental changes from SSLv3 to TLS 1.2, and that the most 640 widely-encountered protocol version from that branch is more than 641 fifteen years old, it's likely that TLS 1.3 deployment outside of 642 constantly-updated web browsers may take one to two decades, or may 643 never happen at all given that a move to TLS 1.2 is an incremental 644 change from TLS 1.0 while TLS 1.3 requires the implementation of a 645 new protocol. This document takes the position that if a protocol 646 from the TLS 1.0 - 1.2 branch will remain in use for decades to come, 647 it should be the best form of TLS 1.2 available. 649 The second reason why this document exists has already been mentioned 650 above, that while TLS 1.0 - 1.2 are all from the same fairly similar 651 family, TLS 1.3 is an almost entirely new protocol. As such, it 652 rolls back the 20 years of experience that we have with all the 653 things that can go wrong in TLS and starts again from scratch with a 654 new protocol based on bleeding-edge/experimental ideas, mechanisms, 655 and algorithms. When SSLv3 was introduced, it used ideas that were 656 10-20 years old (DH, RSA, DES, and so on were all long-established 657 algorithms, only SHA-1 was relatively new). These were mature 658 algorithms with large amounts of research published on them, and yet 659 we're still fixing issues with them 20 years later (the DH algorithm 660 was published in 1976, SSLv3 dates from 1996, and the latest DH 661 issue, Logjam, dates from 2015). With TLS 1.3 we currently have zero 662 implementation and deployment experience, which means that we're 663 likely to have another 10-20 years of patching holes and fixing 664 protocol and implementation problems ahead of us. 666 It's for this reason that this specification uses the decades of 667 experience we have with SSL and TLS and the huge deployed base of TLS 668 1.0 - 1.2 implementations to update TLS 1.2 into a known-good form 669 that leverages about 15 years of analysis and 20 years of 670 implementation experience, rather than betting on what's almost an 671 entirely new protocol based on experimental ideas, mechanisms, and 672 algorithms, and hoping that it can be deployed in less than a decade- 673 or multi-decade time frame. The intent is to create a long-term 674 stable protocol specification that can be deployed once as a minor 675 update to existing TLS implementations, not deployed as a new from- 676 scratch implementation and then patched, updated, and fixed 677 constantly for the lifetime of the equipment that it's used with. 679 4. Security Considerations 681 This document defines a minimal, known-good subset of TLS 1.2 that 682 attempts to address all known weaknesses in the protocol, mostly by 683 simply removing known-insecure mechanisms but also by updating the 684 ones that remain to take advantage of many years of security research 685 and implementation experience. As an example of its efficacy, 686 several attacks on standard TLS that emerged after this document was 687 first published were countered by the mechanisms specified here, with 688 no updates or changes to TLS-LTS implementations being necessary to 689 deal with them. 691 4.1. Security Properties Provided by TLS-LTS 693 If implemented correctly, TLS will provide confidentiality and 694 integrity protection of traffic, and guarantees liveness of the 695 communications. In some circumstances it also provides 696 authentication, see below. Apart from that, it provides no other 697 guarantees. 699 4.2. Security Properties Not Provided by TLS-LTS 701 TLS does not in general protect against spoofing (most commonly 702 encountered on the web as phishing). The one exception is when one 703 of the PSK mechanisms, which provides mutual cryptographic 704 authentication of client and server, is used. PKI, a mechanism 705 outside of TLS, is expected to provide protection against spoofing, 706 but in practice rarely does so. 708 Unless implemented very carefully, TLS does not provide strong 709 protection against side-channel attacks. While this document 710 specifies countermeasures against timing and oracle side-channels 711 that should be employed, these are very difficult to get right and 712 not always effective. 714 TLS provides no real protection against traffic analysis. While the 715 protocol specification contains provisions for message padding, this 716 has little effect on attackers in practice. 718 In the presence of implementation flaws (bugs) or hardware or 719 software errors, some TLS mechanisms may fail catastrophically. AES- 720 GCM is fatally vulnerable to nonce reuse or repeated counter/IV 721 values. AES-CBC in contrast can be arbitrarily abused, for example 722 by setting the IV to the constant value zero, with at most a slight 723 degradation in security (reduction to ECB mode) rather than a 724 complete loss of security. 726 TLS provides no availability guarantees. In fact since it increases 727 susceptibility to failures, either genuine or artificially-induced 728 (for example due to an expired certificate that's otherwise fully 729 valid), it reduces overall availability. 731 TLS provides no guarantees of non-repudiation, access control, or 732 authorisation. These services must be provided by external 733 mechanisms. 735 In short, TLS provides confidentiality (if the crypto is implemented 736 properly and steps are taken to protect against faults and failures), 737 integrity protection, and in some limited cases authentication. It 738 does not provide any other service. If further security services are 739 required, these must be provided through additional, external 740 mechanisms. 742 TLS is a cryptographic protocol, not security pixie dust. Before 743 deciding to employ it, you should evaluate whether it actually 744 provides the security services that you think it does. 746 5. IANA Considerations 748 IANA has added the extension code point TBD (0xTBD) for the tls_lts 749 extension to the TLS ExtensionType values registry as specified in 750 TLS [2]. 752 6. Acknowledgements 754 The author would like to thank contributors from various embedded 755 system vendors for their feedback on this document. 757 7. References 758 7.1. Normative References 760 [1] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, March 1997. 763 [2] Dierks, T. and E. Rescorla, "The Transport Layer Security 764 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 766 [3] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 767 for TLS", RFC 5929, July 2010. 769 [4] Eastlake 3rd, D., "Transport Layer Security (TLS) 770 Extensions", RFC 6066, January 2011. 772 [5] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 773 Security Version 1.2", RFC 6347, January 2012. 775 [6] Gutmann, P., "Encrypt-then-MAC for Transport Layer 776 Security (TLS) and Datagram Transport Layer Security 777 (DTLS)", RFC 7366, September 2014. 779 [7] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 780 Suite Value (SCSV) for Preventing Protocol Downgrade 781 Attacks", RFC 7507, April 2015. 783 [8] Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 784 A., and M. Ray, "Transport Layer Security (TLS) Session 785 Hash and Extended Master Secret Extension", RFC 7627, 786 September 2015. 788 [9] "Digital Signature Standard (DSS)", FIPS 186, July 2013. 790 [10] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 791 Standards (PKCS) #1: RSA Cryptography Specifications 792 Version 2.1", RFC 3447, February 2003. 794 7.2. Informative References 796 [11] Bhargavan, K., Fournet, C., Kohlweiss, M., Pironti, A., 797 Strub, P., and S. Zanella-Beguelin, "Proving the TLS 798 handshake secure (as is)", Springer-Verlag LNCS 8617, 799 August 2014. 801 [12] Brzuska, C., Fischlin, M., Smart, N., Warinschi, B., and 802 S. Williams, "Less is more: relaxed yet compatible 803 security notions for key exchange", IACR ePrint 804 archive 2012/242, April 2012. 806 [13] Dowling, B. and D. Stebila, "Modelling ciphersuite and 807 version negotiation in the TLS protocol", Springer-Verlag 808 LNCS 9144, June 2015. 810 [14] Firing, T., "Analysis of the Transport Layer Security 811 protocol", June 2010. 813 [15] Gajek, S., Manulis, M., Pereira, O., Sadeghi, A., and J. 814 Schwenk, "Universally Composable Security Analysis of 815 TLS", Springer-Verlag LNCS 5324, November 2008. 817 [16] Jager, T., Kohlar, F., Schaege, S., and J. Schwenk, "On 818 the security of TLS-DHE in the standard model", Springer- 819 Verlag LNCS 7417, August 2012. 821 [17] Shrimpton, T., "A long answer to the simple question, "Is 822 TLS provably secure?"", Workshop on Theory and Practice in 823 Cryptography 2012, January 2012. 825 [18] Giesen, F., Kohlar, F., and D. Stebila, "On the security 826 of TLS renegotiation", ACM CCS 2013, November 2013. 828 [19] Meyer, C. and J. Schwenk, "Lessons Learned From Previous 829 SSL/TLS Attacks - A Brief Chronology Of Attacks And 830 Weaknesses", Cryptology ePrint Archive 2013/049, January 831 2013. 833 [20] Krawczyk, H., Paterson, K., and H. Wee, "On the security 834 of the TLS protocol", Springer-Verlag LNCS 8042, August 835 2013. 837 [21] Wee, H., "On the Security of SSL/TLS", Workshop on Theory 838 and Practice in Cryptography 2014, January 2014. 840 [22] Stebila, D., "Provable security of advanced properties of 841 TLS and SSH", Workshop on Theory and Practice in 842 Cryptography 2014, January 2014. 844 [23] Beurdouche, B., Bhargavan, K., Delignat-Lavaud, A., 845 Fournet, C., Kohlweiss, M., Pironti, A., Strub, P., and J. 846 Zinzindohoue, "A Messy State of the Union: Taming the 847 Composite State Machines of TLS", IEEE Symposium on 848 Security and Privacy 2015, May 2015. 850 [24] Bhargavan, K. and M. Kohlweiss, "Triple Handshake: Can 851 cryptography, formal methods, and applied security be 852 friends?", Workshop on Theory and Practice in 853 Cryptography 2015, January 2015. 855 [25] Beurdouche, B., Delignat-Lavaud, A., Kobeissi, N., 856 Pironti, A., and K. Bhargavan, "FLEXTLS: A Tool for 857 Testing TLS Implementations", Workshop on Offensive 858 Technologies 2015, August 2015. 860 [26] Somorovsky, J., "Systematic Fuzzing and Testing of TLS 861 Libraries", Proceedings of the Conference on Computer and 862 Communications Security 2016, October 2016. 864 [27] Holz, R., Amann, J., Mehani, O., Wachs, M., and M. Kaafar, 865 "TLS in the Wild: An Internet-Wide Analysis of TLS-Based 866 Protocols for Electronic Communication", Network and 867 Distributed System Security Symposium 2016, February 2016. 869 [28] "Devices Profile for Web Services Version 1.1", OASIS 870 Standard wsdd-dpws-1.1-spec-os, July 2009. 872 [29] "Power systems management and associated information 873 exchange - Data and communications security - Part 3: 874 Communication network and system security - Profiles 875 including TCP/IP", IEC Standard 62351-3, 2007. 877 [30] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 878 Diffie-Hellman groups for Internet Key Exchange (IKE)", 879 RFC 3526, May 2003. 881 [31] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 882 Groups for Use with IETF Standards", RFC 5114, January 883 2008. 885 [32] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 886 Ephemeral Parameters for Transport Layer Security (TLS)", 887 RFC 7919, August 2016. 889 Author's Address 891 Peter Gutmann 892 University of Auckland 893 Department of Computer Science 894 University of Auckland 895 New Zealand 897 Email: pgut001@cs.auckland.ac.nz