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