idnits 2.17.1 draft-cairns-tls-session-key-interface-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 135: '... MUST meet. Section 5 describes the...' RFC 2119 keyword, line 371: '...on using the SKI MUST be mutually auth...' RFC 2119 keyword, line 383: '... SKI MUST be designed with strong ac...' RFC 2119 keyword, line 417: '...the Edge Servers MUST be logged and au...' RFC 2119 keyword, line 420: '...rom Edge Servers MUST be globally moni...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 235 has weird spacing: '... Client are t...' == Line 238 has weird spacing: '... Server are t...' == Line 245 has weird spacing: '... Server hosts...' == Line 552 has weird spacing: '...essages is th...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: 'error' Included in SKI responses to indicate a fatal error. Can take one of the values 'request denied', 'spki not found', 'malformed request', or 'unspecified error'. SHALL not be sent together with 'output'. -- The document date (October 19, 2015) is 3083 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '28' on line 539 == Unused Reference: 'RFC5054' is defined on line 1000, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'HEART' ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2546 (Obsoleted by RFC 2772) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Downref: Normative reference to an Informational RFC: RFC 5054 ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 6091 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 18 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Cairns 3 Internet-Draft Washington State University 4 Intended status: Standards Track J. Mattsson 5 Expires: April 21, 2016 R. Skog 6 D. Migault 7 Ericsson 8 October 19, 2015 10 Session Key Interface (SKI) for TLS and DTLS 11 draft-cairns-tls-session-key-interface-01 13 Abstract 15 This document describes a session key interface that can be used for 16 TLS and DTLS. The Heartbleed attack has clearly illustrated the 17 security problems with storing private keys in the memory of the TLS 18 server. Hardware Security Modules (HSM) offer better protection but 19 are inflexible, especially as more (D)TLS servers are running on 20 virtualized servers in data centers. 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 April 21, 2016. 39 Copyright Notice 41 Copyright (c) 2015 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 59 4. TLS Session Key Interface Architecture . . . . . . . . . . . 5 60 4.1. Architecture Overview . . . . . . . . . . . . . . . . . . 6 61 4.2. Security Analysis . . . . . . . . . . . . . . . . . . . . 6 62 4.2.1. Edge Server . . . . . . . . . . . . . . . . . . . . . 6 63 4.2.2. Key Server . . . . . . . . . . . . . . . . . . . . . 8 64 4.2.3. Communication and SKI . . . . . . . . . . . . . . . . 9 65 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 9 66 5. Session Key Interface (SKI) . . . . . . . . . . . . . . . . . 10 67 5.1. SKI Protocol Overview . . . . . . . . . . . . . . . . . . 12 68 5.1.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 5.1.2. Ephemeral Diffie Hellman . . . . . . . . . . . . . . 14 70 5.2. SKI Specification . . . . . . . . . . . . . . . . . . . . 14 71 5.2.1. Key Server Processing . . . . . . . . . . . . . . . . 16 72 6. Interaction with TLS Extensions . . . . . . . . . . . . . . . 16 73 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 7.1. ECDHE_ECDSA Key Exchange . . . . . . . . . . . . . . . . 17 75 7.1.1. SKI Request and Response with JSON/HTTP . . . . . . . 17 76 7.1.2. SKI Request and Response with CBOR/CoAP . . . . . . . 19 77 7.2. Static RSA Key Exchange . . . . . . . . . . . . . . . . . 19 78 7.2.1. SKI Request and Response with JSON/HTTP . . . . . . . 20 79 7.2.2. SKI Request and Response with CBOR/CoAP . . . . . . . 20 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 86 1. Introduction 88 Transport Layer Security (TLS) is specified in [RFC5246] and the 89 Datagram Transport Layer Security (DTLS), which is based on TLS, is 90 specified in [RFC6347]. During the TLS handshake, the TLS client and 91 the TLS server exchange a symmetric session key called the premaster 92 secret. From the premaster secret, the client random, and the server 93 random, the endpoints derive a master secret, which in turn is used 94 to derive the traffic encryption keys and IVs. The TLS server is 95 authenticated during this process by presenting a certificate and 96 then proving possession of the private key corresponding to the 97 public key in the certificate. 99 An important principle in designing security architectures is to 100 limit access to keying material, especially long-lived secrets such 101 as private keys. The Heartbleed attack [HEART] has illustrated the 102 dangers of storing private keys in the memory of the TLS server. 104 The TLS Session Key Interface (SKI) defined in this document makes it 105 possible to store private keys in a highly trusted key server, 106 physically separated from client facing servers. With TLS SKI (see 107 Figure 1), the TLS Server is split into two distinct entities called 108 Edge Server and Key Server that communicate over an encrypted and 109 mutually authenticated channel using e.g. TLS. The Edge Server can 110 be placed close to the clients, reducing latency, while the Key 111 Server is placed in a safe location. One important use case is an 112 origin that operates a number of distributed HTTPS servers. The 113 public certificates (not private keys) are pre-provisioned in the 114 Edge Server. The Key Server handles all the private key operations. 115 It retains control of the private keys and can at any time reject a 116 request from the Edge Server, e.g. if there is reason to suspect that 117 the Edge Server has been compromised. 119 The interface SKI uses modern web technologies like JSON, CBOR, HTTP, 120 CoAP, TLS, and REST. SKI supports the most commonly used key 121 exchange methods DHE_RSA, ECDHE_ECDSA, ECDHE_RSA, and RSA, together 122 with X.509 [RFC5280] or raw public key [RFC7250] authentication. It 123 does not work with PSK or SRP authentication. Even though the 124 industry is quickly moving towards the more secure ECDHE key exchange 125 methods, which provides perfect forward secrecy, static RSA still 126 needs be supported in many deployments. 128 The remaining of the document is as follows. Section 2 defines the 129 terms used in this document. Section 3 describes the problem 130 statement and the need to centralize the private key operations to a 131 centralized Key Server as well as a standard interface to 132 interoperate with the Key Server. The resulting architecture is 133 detailed in Section 4 followed by a security analysis and security 134 requirements the different components as well as the SKI interface 135 MUST meet. Section 5 describes the SKI and defines a specific SKI 136 implementation based on HTTP and JSON. Section 6 position the SKI 137 toward the different TLS extensions, and Section 7 illustrates the 138 described SKI with examples. 140 2. Terminology 142 TLS Client 144 TLS Server 146 Edge Server 148 Key Server 150 SKI 152 3. Problem Statement 154 With TLS, a TLS Client can set up an authenticated and encrypted 155 channel with a TLS Server. Authentication of the TLS Server as well 156 as the negotiation of the TLS Session Keys are performed during the 157 TLS hand shake. The TLS hand shake as described in [RFC5246] details 158 two methods: RSA and ephemeral Diffie Hellman. In both case, the TLS 159 Server is expected to perform some cryptographic operations based on 160 a private key and thus requires to have access to the private key. 161 When a single server is involved, the key is expected to be hosted by 162 the server. However, numerous web applications cannot be hosted by a 163 single TLS Server. Most of the time multiple TLS Servers are needed. 164 In addition, multiple cloud provider or hosting providers provides 165 resource elasticity by instantiating TLS Servers and placing these 166 servers at the edge of the network in order to address the demand and 167 reduce latency. The various instances of TLS Server may be inside a 168 singe domain or across multiple domains like a private cloud combined 169 with other third party cloud providers. 171 As each instance of the TLS Server needs to be able to perform some 172 cryptographic operation with the private key, a number of ways may be 173 envisioned: 175 - 1) The cryptographic material, e.g. the private key is shared 176 between all TLS Server instances 178 - a) Cryptographic material is copied into the various 179 instances of the TLS Server 181 - b) Cryptographic material is outsourced and accessed by all 182 instances of TLS Servers 184 - 2) The cryptographic material is not shared and each instance has 185 its own cryptographic material 187 At first, hosting private key in memory of the TLS Server exposes the 188 cryptographic material to leakage as illustrated by the Heartbleed 189 attack [HEART]. One common practice used to protect keys is to 190 delegate the private key operations to a separate entity such as a 191 Hardware Security Module (HSM), something that is supported in many 192 TLS libraries. HSMs provide good security but are inflexible and may 193 be difficult to deploy when the TLS server runs on a virtualized 194 machine in the cloud, especially if the application server that uses 195 TLS moves between different data centers. Furthermore, while HSMs 196 protect against extraction of the private key, they do not protect 197 against misuse in case an adversary gains possession of the HSM 198 itself. In fact, an attacker taking control of the HSM can use the 199 HSM to encrypt (resp. decrypt) any clear text (resp. encrypted text). 200 Similarly, the use of a network-attached HSM does not prevent a 201 corrupted client to have provide the full access to encryption / 202 decryption unless some control access is performed to the data 203 provided. In general, access control policies on the data encrypted 204 / decrypted by the HSM are not provided. In addition, communication 205 protocols of HSM are specific HSM vendor. There are several other 206 proprietary session key interfaces deployed but no standardized 207 solution. 209 Then, copying private keys in multiple instances increases the 210 surface of attack is even increases the surface of attack with the 211 number of instances of TLS Server. One way to limit the surface of 212 attack is to use a public / private key generated for each instance 213 of TLS Server. More specifically, when a TLS Server instance is 214 corrupted, the and the attacker get access to the private key, this 215 key cannot be used for another instance. However, splitting keys per 216 instance comes also with some additional drawbacks. For example, 217 session resumption does not work between multiple instances of TLS 218 Servers. In addition, all newly generated public keys of each TLS 219 Servers needs to be signed by the Certificate Authority, which comes 220 with an additional management overhead. 222 The proposed TLS Session Key Interface Architecture proposes to have 223 a common cryptographic material hold by the Key Server shared by all 224 instances of the TLS Servers. In addition, the interface between the 225 TLS Severs and the Key Server is limited enforced to strong access 226 control policies so to limit the scope of use of the encryption / 227 decryption capabilities of the Server Key. 229 4. TLS Session Key Interface Architecture 230 4.1. Architecture Overview 232 The TLS Session Key Interface Architecture is composed of three main 233 components as described in Figure 1: 235 TLS Client are typically all web browsers or any TLS Client 236 initiating an handshake with the TLS Server. 238 Edge Server are the TLS Server part seen by the TLS Client. It is 239 designated as an Edge Server as it does not host the private 240 key of the TLS Server. Instead, when the private key is 241 involved, the cryptographic operation is performed by the Key 242 Server. Edge Servers are expected to be placed close to the 243 TLS Client in order to reduce the latency. 245 Key Server hosts the private key and performs the cryptographic 246 operations on behalf of the Edge Server. Note that the Key 247 Server may be connected to a HSM for example. In addition, 248 they may be a single Key Server or multiple Key Servers. 250 In order to implement the SKI, the servers implementations and TLS 251 libraries should make private key operation non blocking. 253 +------------+ Handshake +-------------+ SKI +------------+ 254 | TLS Client | <---------> | Edge Server | <-------> | Key Server | 255 +------------+ +-------------+ +------------+ 257 Figure 1: TLS Session Key Interface Architecture 259 4.2. Security Analysis 261 4.2.1. Edge Server 263 Edge Servers are serving the TLS traffic of the TLS Clients. Edge 264 Servers performs all necessary operations except the cryptographic 265 operations involving the private keys associated to the TLS Server. 267 If an Edge Server becomes compromised, an attacker is still likely to 268 perform some operations with the private key of the TLS Server by 269 interacting with the Key Server. The corrupted Edge Server may, for 270 example, generate the TLS master secrets and impersonates the Edge 271 Server. However, such attacks are not different from those that 272 existed on TLS Server. 274 The presented architecture presents the following advantages. First 275 the private key remains protected and cannot be retrieved by the 276 attacker. This was obviously not the case when the key was hosted on 277 the corrupted TLS Server. Then, the attack is contained to the 278 communications involving the Edge Servers. The corrupted Edge Server 279 does not compromise the other Edge Servers in the same way as when 280 the private key of the TLS Server is copied on all Edge Servers. 281 With the presented architecture, addressing the attack locally to the 282 corrupted Edge Server is sufficient. Note that in the case Edge 283 Servers are dynamically provisioned, it is likely that the 284 vulnerability found on one Edge Server may be also be found on other 285 Edge Servers. Such consideration are out of scope of the proposed 286 architecture, and are inherent to deployment cloning VMs or 287 instantiating VMs with an identical configuration. At last, Edge 288 Servers are not working on their own and still require some 289 communications with a centralized Key Server. Such communications 290 with the Key Server may also be used to qualify the activities of the 291 Edge Servers, and thus used to detect any abnormal behaviors. This 292 of course requires the Key Server to log and monitor the Edge 293 Servers' activities. 295 If an Edge Server becomes compromised, an attacker may perform 296 attacks such as chosen plain text attacks if it can request clear 297 text data to be encrypted or chosen cipher text attacks in case it 298 can provide encrypted data and get the corresponding clear text. One 299 way to limit such attacks is to monitor the activity of the Edge 300 Servers, and raise an alarm when suspicious activity has been 301 detected. In case the Edge Server has been tagged with a suspicious 302 activity, further investigations and audit may be performed on line 303 if the Edge Server is still running or off line otherwise. One way 304 to increase the difficulty of performing such attack is to make the 305 chosen text harder. This could be handled at the API level for 306 example, as detailed in Section 4.2.3. 308 A similar attack may be performed in an orchestrated way, for example 309 when multiple Edge Servers are compromised and are collaborating. 310 Collaboration may be used to perform a chosen plain text attack or a 311 chosen cipher text attack for example. The advantage of using 312 multiple compromised Edge Servers, is that the various requests are 313 less likely to be detected than if being sent by a single Edge 314 Server. Such attacks may be detected by monitoring the traffic not 315 on a per-Edge Server basis, but instead globally, and for example 316 look at the randomness distribution of the provided clear text or 317 cipher text. 319 If a Edge Server has been compromised and its private key has be 320 retrieved by the attacker, the attacker, is then able to send request 321 to the Key Server on behalf of the Edge Server. If the credentials 322 are not bound to the IP addresses, the queries attack may even be 323 performed from another host or IP address than the Edge Server. 325 4.2.2. Key Server 327 The Key Server is a crucial element of the architecture which 328 centralizes all the cryptographic operations involving the private 329 key of the TLS Server. The responsibility of the Key Server is top 330 keep the private key secret, while keeping the service available. 332 Although the Figure 1 represents only one Key Server, the 333 architecture may have multiple Key Servers in order to address the 334 traffic load or in order to provide high availability. Increasing 335 the number of Key Servers increases the surface of attack and so the 336 risk of leakage for the private key. 338 Even though the number of Key Servers may increase it number is 339 expected to remain way below the number of Edge Servers of TLS 340 Servers with a copy of the private key. As a result, the risks are 341 still reduced by several orders of magnitudes. 343 Increasing the number may also require some coordinated monitoring. 344 In fact, a single Key Server provides some centralized way to control 345 the cryptographic operations requested globally and for each 346 individual Edge Server. With multiple Key Servers, such analyze may 347 not be performed solely within the Key Server. Instead, logging data 348 may be outsourced to another component that performs the analysis. 350 If Key Server becomes compromised, the attacker is able to decrypt 351 any cypher text encrypted with the public key. More especially, an 352 attacker is able to read the server and client randoms as well as the 353 pre-master secret and then generate the session key. This is true 354 for on path traffic, but also for recorded traffic. For that purpose 355 it is recommended to favor key exchanges that enforce perfect forward 356 secrecy. In other words RSA is not recommended as specified in 357 section F.1.1.2 of [RFC5246]. 359 Key Servers centralize all cryptographic operations performed with 360 the private key of the TLS Servers. This provides the Key Servers a 361 bottle neck position. If the Key Servers undergo a DoS or DDoS 362 attack, they can prevent the Edge Servers to set TLS sessions. Key 363 Servers should be over provisioned, and should be able to rate limit 364 requests from Edge Servers. In addition to authenticated traffic, 365 the Edge Server should be able to detect when traffic is being 366 replayed or when the identity of an Edge Server has been usurped - 367 like the Edge Server being stolen its private key. 369 4.2.3. Communication and SKI 371 The communication using the SKI MUST be mutually authenticated and 372 encrypted in order to have a malicious node hijacking the 373 communication or pretending its is a legitimate Edge Server and 374 serving TLS Clients. 376 Similarly, the communication between Edge Servers and Key Server 377 should be encrypted in order to avoid a malicious nodes to collect a 378 collection of clear text with their associated encrypted text and 379 eventually perform a replay attack. 381 TLS or IPsec are good candidates too secure the SKI communication. 383 SKI MUST be designed with strong access control in order to limit the 384 scope of actions performed by an authorized Edge Servers. This may 385 be performed by checking the properties of the inputs as well as 386 defining which inputs and actions are permitted. 388 Inputs provided to the Key Servers should be considered in order to 389 reduce the surface of attack. Suppose the Edge Server needs to 390 encrypt the hash of two random number. One way could do is first let 391 the Edge Server hash the two random number and then ask the Key 392 Server to encrypt the resulting hash. Such design exposes the Key 393 Server to clear text attack as, any fixed value value could be fixed 394 to the hash. On the other hand, the Edge Server could also provide 395 the two numbers to the Key Server, which in turn perform the hash 396 followed by the encryption. Doing so provides less control to the 397 Edge Server for choosing the clear text. Note also that in the 398 second case, the Key Server is performing more operations, and 399 communications may involve more data to be carried. As a result, 400 security and performance may be balanced. 402 Similarly, parameters provided should be strictly controlled in order 403 to narrow the scope of clear text / cipher text chosen attacks, and 404 when possible, length or syntax should be checked. In addition, when 405 an error occurs, the Key Server should limit the information provided 406 to the Edge Server. For example, it may be better to simply reject 407 the request with a general error message that does not specify the 408 specific error encountered, so this information may not be used by 409 the attacker. On the other hand, th error should be logged 410 precisely, so it may be used during the analysis. 412 4.3. Security Requirements 414 Here are the following requirements or recommendations regarding the 415 architecture. 417 REQ 1: The activity of the Edge Servers MUST be logged and audited 418 in order to detect suspicious activity. 420 REQ 2: The request from Edge Servers MUST be globally monitored in 421 order to detect some orchestrated attacks not detected at the 422 Edge Server level. 424 REQ 3: RSA based authentication is not recommended to preserve TLS 425 Client privacy and confidentiality in case of Key Server 426 leakage. 428 REQ 4: The communication between the Edge Server and the Key Server 429 MUST be mutually authenticated and encrypted. The use of 430 perfect forward secrecy cypher suites is recommended. 432 REQ 5: SKI MUST be designed to limit the possible operations 433 performed by the Edge Server. This involves strict control 434 of the parameters as well as specific design to avoid clear 435 text or cipher attacks. 437 REQ 6: SKI MUST NOT provide the Edge Server extra information in 438 case an error occurs. 440 REQ 7: SKI and Key Server MUST be monitored and logged to enable 441 further investigation and analysis. 443 5. Session Key Interface (SKI) 445 TLS provides different methods in order to agree on the pre_master 446 secret. One way - designated as "rsa" in [RFC5246] - consists in the 447 TLS Client provides the pre_master secret encrypted in a Client Key 448 Exchange message. The TLS Client encrypts the pre_master with the 449 public key previously provided by the server in a Server Certificate 450 message. 452 Other methods are based on the Diffie Hellman approach, which 453 provides perfect forward secrecy. As described in section F.1.1.3 of 454 [RFC4346], the TLS Server can either provide fixed Diffie Hellman 455 parameters in a Server Certificate message or provide ephemeral 456 Diffie Hellman parameters. In the first case, the TLS Client may 457 authenticate the Server Certificate with a DSA, RSA, ECDSA signature. 458 The TLS Server provides certificates the TLS Client is able to check. 459 In other words, the signature uses hash function and signature 460 algorithms supported by the TLS Client. When Diffie Hellman is not 461 authenticated, then the Diffie Hellman value is not provided in the 462 Server Certificate message. Instead, it is provided in an additional 463 Key Server Exchange message. In the second case, when ephemeral 464 Diffie Hellman values are provided the value is embedded in a Key 465 Server Exchange message with an additional Signature structure. The 466 Signature is computed by the TLS Server over the hash of the 467 ephemeral Diffie Hellman key together with a set of temporary values 468 (the ClientHello.random and the ServerHello.random) to avoid replay 469 attacks. The TLS Server provides the signature in accordance to the 470 hash and signature function supported by the TLS Client as well as 471 the key provided by the TLS Server in the Certificate message. 473 As a result, the private key of the TLS Server is only involved when 474 the following key exchanges algorithm (KeyExchangeAlgorithm) are 475 agreed between the TLS Client and the Edge Server: 477 RSA when the pre_master is entirely generated by the TLS_Client and 478 encrypted by the TLS Client in a Client Key Exchange message. 479 This authentication method is defined in [RFC5246]. 481 DHE_RSA when the hash of the ephemeral Diffie Hellman key associated 482 to the temporary values is signed with the RSA private key. This 483 is defined in [RFC5246]. 485 ECDHE_RSA Similar as above but with Elliptic Curve Diffie Hellman 486 values with an RSA signature. This method is defined in 487 [RFC4492]. 489 ECDHE_ECDSA Similar as above but with elliptic curve signature. 490 This method is defined in [RFC4492]. 492 The following document only considers these key exchange protocols. 493 If another key exchange protocol is negotiated, as currently defined, 494 there is no need to perform cryptographic operations involving the 495 private key. As a result, such key exchange protocols do not require 496 the Edge Server to interact with the Key Server, and are not 497 considered in this document. Instead, Edge Server should be 498 provisioned with the appropriated certificates. 500 DISCUSSION: It is not clear to me why DHE_DSS does not sign the 501 DHParameters. 503 This section designs the SKI. Section 5.1 provides an overview of 504 the SKI. More specifically, it describes the information that is 505 communicated between the Edge Server and the Key Server, but does not 506 provide any details on the protocols used to exchange these 507 information, nor how the private key is being identified. This is 508 left to Section 5.2 provides a specific implementation based on JSON 509 and HTTP. 511 5.1. SKI Protocol Overview 513 This section describes the interactions between the TLS Client, the 514 Edge Server and the Key Server when either RSA or ephemeral Diffie 515 Hellman (DHE_RSA, ECDHE_RSA or ECDHE_ECDSA) key agreement have been 516 agreed between the TLS Client an dthe Edge Server. 518 The description of this section applies for TLS 1.0 [RFC2246], TLS 519 1.1 [RFC4346], TLS 1.2 [RFC5246], DTLS 1.0 [RFC4347], DTLS 1.1 520 [RFC4347] and DTLS 1.2 [RFC6347]. 522 5.1.1. RSA 524 In TLS1.2 [RFC5246] every session has a "master_secret" generated 525 from a pre_master. [RFC5246] and [RFC7627] defines different ways to 526 generate the master_secret from the pre_master. However, the way the 527 pre_master is agreed remains similar. 529 For information, in [RFC5246], the master_secret is generated as 530 follows: 532 master_secret = PRF(pre_master_secret, "master secret", 533 ClientHello.random + ServerHello.random) 534 [0..47]; 536 where: 537 struct { 538 uint32 gmt_unix_time; # 4 bytes 539 opaque random_bytes[28]; 540 } Random; 542 master_secret 544 [RFC7627] defines the Extended Master Secret Extension where the 545 "master_secret" is defined as follows: 547 master_secret = PRF(pre_master_secret, "extended master secret", 548 session_hash) 549 [0..47]; 550 where: 551 - session_hash = Hash(handshake_messages) 552 - handshake_messages is the concatenation of all the exchanged 553 Handshake structures, as defined in Section 7.4 of [RFC5246]. 554 - Hash is as defined in Section 7.4.9 of [RFC5246] 556 As defined in section 8.1.1 [RFC2546], the pre_master is 48-byte 557 generated by the TLS Client. The two first bytes indicates the TLS 558 version and MUST be the same value as the one provided by the 559 ClientHello.client_version, and the remaining 46 bytes are expected 560 to be random. 562 The pre_master is encrypted with the public key of the TLS Server as 563 a EncryptedPreMasterSecret structure sent in the Client Key Exchange 564 Message as described in section 7.4.7.1 [RFC5246]. The encryption 565 follows for compatibility with previous TLS version RSAES-PKCS1-v1_5 566 scheme described in [RFC3447], which results in a 256 byte encrypted 567 message for a 2048-bit RSA key or 128 byte encrypted message for a 568 1024 bit RSA key. 570 <---------- 256 bytes ------------------------------> 571 <-- 205 bytes --> <- 48 bytes -> 572 <- TLS -> 573 version 574 +----+----+------------------+----+-----+-----+--------+ 575 | 00 | 02 | non-zero padding | 00 | maj | min | random | 576 +----+----+------------------+----+-----+-----+--------+ 578 PKCS#1 padding for pre_master secret encrypted with 2048-bit RSA key 580 Upon receiving a Client Key Exchange Message with a 581 KeyExchangeAlgorithm set to rsa, the Edge Server sends a request for 582 the pre_master to the Key Server. The request provides the 583 EncryptedPreMasterSecret as well as the ClientHello.client_version. 585 Upon receiving the EncryptedPreMasterSecret and the 586 ClientHello.client_version, the Key Server decrypts the 587 EncryptedPreMasterSecret following [RFC3447]. If the decryption is 588 successful, the Key Server MUST check the version indicated in the 589 two first bytes corresponds to the ClientHello.client_version as well 590 as the length of the clear text pre_master. If one of the test 591 fails, the Key Server MUST return an 'malformed request' error. If 592 any other error occurs an 'unspecified error' MUST be returned. If 593 it is successful, the Key Server returns the clear text of the 594 pre_master. 596 Upon receiving the response or the error, the Edge Server proceeds as 597 defined in [RFC2546]. If the pre_master is provided, the Edge Server 598 computes the master_secret as defined in [RFC5246] or in [RFC7627]. 599 If an error is returned, the Edge Server continue the exchange with a 600 randomly generated pre_master. 602 DISCUSSION: if SKI is the interface between the Edge Server and the 603 Key Server, maybe we could return the master_secret directly. Maybe 604 an architecture with a Master Oracle and Key Server would better 605 split the function between owning the private key - and only 606 decrypting - and providing the master with associate TLS syntax 607 checking. 609 5.1.2. Ephemeral Diffie Hellman 611 [RFC5246] defines how the TLS Client and the Edge Server agrees for 612 DHE_RSA. When the KeyExchangeAlgorythm has been agreed to dhe_rsa, 613 as defined in section 7.4.3 of [RFC5246], the ServerKeyExchange 614 message contains ServerDHParams as well as the Signature. 616 [RFC4492] defines the extension that enables the TLS Client and the 617 Edge Server to agree ECDHE_RSA or ECDHE_ECDSA for the key exchange 618 algorithm. When the KeyExchangeAlgorythm has been agreed to 619 ec_diffie_hellman between the TLS Client and the Edge Server, as 620 detailed in section 5.4 of [RFC4492], the ServerKeyExchange contains 621 the ServerECDHParams and Signature. 623 In order to build the signature, the Edge Server provides Key Server 624 the type of the key (ECHDE or DHE), the corresponding public key, the 625 hash function, the signature algorithm to be used (RSA, or ECDSA), 626 the ClientHello.random and the ServerHello.random. 628 Upon receiving the public key, the Key Server checks random numbers 629 are 32bit long, and checks the validity of the public key. If the 630 input data is not valid or has the wrong size, the Key Server MUST 631 reply with a 'malformed request' error. Otherwise the Key Server 632 hash and signs the output. If any error occurs during the signing 633 process, the server responds with an 'unspecified error' error. If 634 signing is successful, the server responds with the output data set 635 to the result of the signing operation. 637 Upon receiving the response or the error, the Edge Server proceeds as 638 defined in [RFC2546]. If the pre_master is provided, the Edge Server 639 computes the master_secret as defined in [RFC5246] or in [RFC7627]. 640 If an error is returned, the Edge Server continue the exchange with a 641 randomly generated pre_master. 643 5.2. SKI Specification 645 The Session Key Interface is based on a request-response pattern 646 where the Edge Server sends a SKI Request to the Key Server 647 requesting a specific private key operation that the Edge Server 648 needs to complete a TLS handshake. The Edge Server's request 649 includes data to be processed, the identifier of the private key to 650 be used, and any options necessary for the Key Server to correctly 651 perform the requested operation. The Key Server answers with a SKI 652 Response containing either the requested output data or an error. 654 Any request-response protocol can be used to carry the SKI payloads. 655 Two obvious choices are the Hypertext Transfer Protocol (HTTP) 656 [RFC7540] and the Constrained Application Protocol (CoAP) [RFC7252]. 657 Which protocol to use is application specific. SKI requests are by 658 default sent to the Request-URI '/ski'. The interface between the 659 Edge Server and the Key Server MUST be protected by a security 660 protocol providing integrity protection, confidentiality, and mutual 661 authentication. If TLS is used, the implementation MUST fulfill at 662 least the security requirements in [RFC7540] Section 9.2. 664 Two formats are defined for the SKI Payload format: the JavaScript 665 Object Notation (JSON) [RFC7159] and the Concise Binary Object 666 Representation (CBOR) [RFC7049]. In JSON, byte strings are Base64 667 encoded [RFC4648]. Which format to use is application specific. The 668 payload consists of a single JSON or CBOR object consisting of one or 669 more attribute-value pairs. The following attributes are defined: 671 'protocol' REQUIRED in SKI requests. Specifies the protocol version 672 negotiated in the handshake between Client and Edge Server. Can 673 take one of the values 'TLS 1.0', 'TLS 1.1', 'TLS 1.2', 'DTLS 674 1.0', or 'DTLS 1.2'. 676 'spki' REQUIRED in SKI requests. Byte string that identifies the 677 Subject Public Key Info (SPKI) of a X.509 certificate [RFC5280] or 678 a raw public key [RFC7250]. Contains a SHA-256 SPKI Fingerprint 679 as defined in [RFC7469] 681 'method' Included in SKI requests to indicate the key exchange 682 method. Can take one of the values 'ECDHE' or 'RSA'. MAY be 683 omitted if the default value 'ECDHE' is used. 685 'hash' Included in SKI requests. MUST be used if a hash algorithm 686 other than the default hash algorithm has been negotiated using 687 the "signature_algorithms" extension. Can take one of the values 688 'SHA-224', 'SHA-256', 'SHA-384', or 'SHA-512'. 690 'input' REQUIRED in SKI requests. Byte string containing the input 691 data to the private key operation. For static RSA it contains the 692 encrypted premaster secret (EncryptedPreMasterSecret). For ECDHE 693 it contains the data to be signed (ClientRandom + ServerRandom + 694 ServerECDHParams). 696 'output' Included in successful SKI responses. Byte string 697 containing the output data from the private key operation. For 698 static RSA it contains the premaster secret (PreMasterSecret). 699 For ECDHE is contains the signature (Signature). 701 'error' Included in SKI responses to indicate a fatal error. Can 702 take one of the values 'request denied', 'spki not found', 703 'malformed request', or 'unspecified error'. SHALL not be sent 704 together with 'output'. 706 5.2.1. Key Server Processing 708 The Key Server determines how to handle a SKI request based on the 709 values provided for the 'protocol', 'spki', 'hash', and 'method' 710 attributes. If the Key Server cannot parse the SKI request it MUST 711 respond with a 'malformed request' error. If a private key matching 712 the 'spki' value is not found, the Key Server MUST respond with a 713 'spki not found' error. If the Edge Server is not authorized to 714 receive a response to the specific request, the Key Server MUST 715 respond with a 'request denied' error. 717 DISCUSSION: For TLS1.0/DTLS1.0 only uses MD5 and SHA-1 are defined. 718 SHA-256 only appears in TLS1.2. I suspect there are some additional 719 checks to be done, or maybe that is fine to have TLS1.0 with these 720 algorithms. 722 6. Interaction with TLS Extensions 724 Most TLS extensions interact seamlessly with SKI, but it is worth 725 noting the few that do not: 727 [RFC6091] defines the use of OpenPGP certificates with TLS. As 728 OpenPGP certificates do not have a SPKI field, SKI will not work 729 with this extension unless the public key identification mechanism 730 is updated. 732 [RFC6962] certificate transparency conflict with the proposed 733 version of SKI since it requires signing of timestamps, while SKI 734 only allows signing of valid ECDHE parameters. 736 A few other TLS extensions may have problems if a TLS client connects 737 to different Edge Servers: 739 [RFC5077] defines session resumption with session tickets. As 740 this extension uses a secret key stored on the server issuing the 741 ticket, it only works if the resumption Edge Server has the same 742 secret key. 744 [RFC5746] defines the renegotiation_info extension for secure 745 renegotiation. As this extension is facilitated by binding the 746 renegotiation to the previous connection, it only works if the 747 renegotiation is done to the same Edge Server. 749 7. Examples 751 Note: Lengths of hexadecimal and base64 encoded strings in examples 752 are not intended to be realistic. For readability, COSE objects are 753 represented using CBOR's diagnostic notation [RFC7049]. 755 7.1. ECDHE_ECDSA Key Exchange 757 If an ECDHE key exchange method is used, the Edge Server MUST receive 758 the SKI Response before it can send the ServerKeyExchange message. 759 An example message flow is shown in Figure 2. 761 +--------+ +-------------+ +------------+ 762 | Client | | Edge Server | | Key Server | 763 +--------+ +-------------+ +------------+ 765 ClientHello (Client Random) 766 ---------------------------------------> 767 ServerHello (Server Random) 768 <--------------------------------------- 769 Certificate (Server Certificate) 770 <--------------------------------------- 771 SKI Request 772 --------------------> 773 SKI Response 774 ServerKeyExchange <-------------------- 775 (ECDHParams, Signature) 776 <--------------------------------------- 777 ClientKeyExchange (ClientDHPublic) 778 ---------------------------------------> 779 Finished 780 <--------------------------------------> 782 Figure 2: Message Flow for ECDHE Key Exchange 784 7.1.1. SKI Request and Response with JSON/HTTP 785 SKI Request: 787 POST /ski HTTP/1.1 788 Host: keyserver.example.com 789 Content-Type: application/json 790 Content-Length: 166 792 { 793 "protocol": "TLS 1.2", 794 "method": "ECDHE", 795 "hash": "SHA-256", 796 "spki": "mPgHXSvrW6ygN4uhPnl0W2uGMSbCDjFV1bfkaVT5", 797 "input": "Bn1eaonvIyCDFd9Ek8UyghL9SA1FXcDplnk8zNlLXBL4H0FAEFyvFO" 798 } 800 SKI Response: 802 HTTP/1.1 200 OK 803 Content-Type: application/json 804 Content-Length: 62 806 { 807 "output": "eysh5GCSbIjjHzDt7Co5PUuVnDePbUYI839yv30bJWquwJ3vyADor" 808 } 810 SKI Request: 812 POST /ski HTTP/1.1 813 Host: keyserver.example.com 814 Content-Type: application/json 815 Content-Length: 128 817 { 818 "protocol": "TLS 1.1", 819 "spki": "p8FU0McKWBBLEEFfQbnJPjW3Q6EcZ5t11cKKcuwj", 820 "input": "yWCMO9P0yINtHUT17ZO1X1mUgwh1CrTGan9QaAGph9AnCO4HA44nez" 821 } 823 SKI Response: 825 HTTP/1.1 200 OK 826 Content-Type: application/json 827 Content-Length: 62 829 { 830 "output": "m7nJUltTVMiaQJyDcKPaq0ZOtfuRVnUt1cUx5KoP3w75MqpSelutO" 831 } 833 7.1.2. SKI Request and Response with CBOR/CoAP 835 SKI Request: 837 Header: POST (T=CON, Code=0.03, MID=0x1337) 838 Uri-Path: "ski" 839 Content-Format: 60 (application/cbor) 840 Payload: { 841 "protocol": "TLS 1.0", 842 "spki": h'a1fa7ec57a6a5485756c45ab58b2c992', 843 "input": h'd2e61706059a16714e4716853e2917e34' 844 } 846 SKI Response: 848 Header: 2.04 Changed (T=ACK, Code=2.04, MID=0x1337) 849 Content-Format: 60 (application/cbor) 850 Payload: { "output": h'2c8a0001b8295ab44d1930b8efdd9fb40' } 852 7.2. Static RSA Key Exchange 854 If the static RSA key exchange method is used, the Edge Server MUST 855 receive the SKI Response before it can send the Finished message. An 856 example message flow is shown in Figure 3. 858 +--------+ +-------------+ +------------+ 859 | Client | | Edge Server | | Key Server | 860 +--------+ +-------------+ +------------+ 862 ClientHello (Client Random) 863 ---------------------------------------> 864 ServerHello (Server Random) 865 <--------------------------------------- 866 Certificate (Server Certificate) 867 <--------------------------------------- 868 ClientKeyExchange 869 (Encrypted Premaster Secret) 870 ---------------------------------------> 871 SKI Request 872 --------------------> 873 SKI Response 874 <-------------------- 875 Finished 876 <--------------------------------------> 878 Figure 3: Message Flow for Static RSA Key Exchange 880 7.2.1. SKI Request and Response with JSON/HTTP 882 SKI Request: 884 POST /ski HTTP/1.1 885 Host: keyserver.example.com 886 Content-Type: application/json 887 Content-Length: 145 889 { 890 "protocol": "TLS 1.2", 891 "method": "RSA", 892 "spki": "QItwmcEKcuMhCWIdESDPBbZtNgfwS7w84wizTk47", 893 "input": "dEHffkdIoi2YhQmsqcum3kDk2cToQqO2JLzJVi4q8pJSvfSUyyhRv7" 894 } 896 SKI Response: 898 HTTP/1.1 200 OK 899 Content-Type: application/json 900 Content-Length: 62 902 { 903 "output": "CtehRGUae6NQ0daIuClSTg3nW62zqPvYTjnvIV0mt5kM49tIq9uDG" 904 } 906 7.2.2. SKI Request and Response with CBOR/CoAP 908 SKI Request: 910 Header: POST (T=CON, Code=0.03, MID=0xabba) 911 Uri-Path: "ski" 912 Content-Format: 60 (application/cbor) 913 Payload: { 914 "protocol": "TLS 1.2", 915 "method": "RSA", 916 "spki": h'8378d0547da09484b8ae509565b0a595', 917 "input": h'9da2d7a363ead429141f4dcad20befb6043' 918 } 920 SKI Response: 922 Header: 2.04 Changed (T=ACK, Code=2.04, MID=0xabba) 923 Content-Format: 60 (application/cbor) 924 Payload: { "output" : h'827628ca533a1d1191acb0e106fb' } 926 8. IANA Considerations 928 This document defines the following. TODO... 930 9. Security Considerations 932 The security considerations in [RFC5246], [RFC4492], and [RFC7525] 933 apply to this document as well. 935 The TLS Session Key Interface increases the security by making it 936 possible to store private keys in a highly trusted location, 937 physically separated from client facing servers. The main feature 938 that separates TLS SKI from traditional TLS is the secure connection 939 between the Edge Server and the Key Server. This connection is 940 relied on to ensure that the servers are mutually authenticated and 941 that the connection between them is private. A compromised Edge 942 Server can still access client data as well as submit requests to the 943 Key Server. However, the risks are reduces since no private keys can 944 be compromised and the Key Server can at any time prevent the Edge 945 Server from starting new TLS connections. 947 A compromised Edge Server could potentially launch timing side- 948 channel attacks or buffer overflow attacks. And as the Key Server 949 has limited knowledge of the input data it signs or decrypts, a 950 compromised edge server could try to get the Key Server to process 951 maliciously crafted input data resulting in a signed message or the 952 decryption of the PreMasterSecret from another connection. However, 953 these attacks are not introduced by SKI since they could be performed 954 on a compromised traditional TLS server and, with the exception of 955 the signing attack, can even be launched by a TLS client against an 956 uncompromised TLS server. 958 10. Acknowledgements 960 The authors would like to thank Magnus Thulstrup and Hans Spaak for 961 their valuable comments and feedback. 963 11. References 965 [HEART] Codenomicon, "The Heartbleed Bug", 966 . 968 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 969 RFC 2246, DOI 10.17487/RFC2246, January 1999, 970 . 972 [RFC2546] Durand, A. and B. Buclin, "6Bone Routing Practice", 973 RFC 2546, DOI 10.17487/RFC2546, March 1999, 974 . 976 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 977 Standards (PKCS) #1: RSA Cryptography Specifications 978 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 979 2003, . 981 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 982 (TLS) Protocol Version 1.1", RFC 4346, 983 DOI 10.17487/RFC4346, April 2006, 984 . 986 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 987 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 988 . 990 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 991 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 992 for Transport Layer Security (TLS)", RFC 4492, 993 DOI 10.17487/RFC4492, May 2006, 994 . 996 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 997 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 998 . 1000 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 1001 "Using the Secure Remote Password (SRP) Protocol for TLS 1002 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 1003 2007, . 1005 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1006 "Transport Layer Security (TLS) Session Resumption without 1007 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1008 January 2008, . 1010 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1011 (TLS) Protocol Version 1.2", RFC 5246, 1012 DOI 10.17487/RFC5246, August 2008, 1013 . 1015 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1016 Housley, R., and W. Polk, "Internet X.509 Public Key 1017 Infrastructure Certificate and Certificate Revocation List 1018 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1019 . 1021 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1022 "Transport Layer Security (TLS) Renegotiation Indication 1023 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 1024 . 1026 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 1027 for Transport Layer Security (TLS) Authentication", 1028 RFC 6091, DOI 10.17487/RFC6091, February 2011, 1029 . 1031 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1032 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1033 January 2012, . 1035 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1036 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 1037 . 1039 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1040 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1041 October 2013, . 1043 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1044 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1045 2014, . 1047 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1048 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1049 Transport Layer Security (TLS) and Datagram Transport 1050 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1051 June 2014, . 1053 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1054 Application Protocol (CoAP)", RFC 7252, 1055 DOI 10.17487/RFC7252, June 2014, 1056 . 1058 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 1059 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 1060 2015, . 1062 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1063 "Recommendations for Secure Use of Transport Layer 1064 Security (TLS) and Datagram Transport Layer Security 1065 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1066 2015, . 1068 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1069 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1070 DOI 10.17487/RFC7540, May 2015, 1071 . 1073 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 1074 Langley, A., and M. Ray, "Transport Layer Security (TLS) 1075 Session Hash and Extended Master Secret Extension", 1076 RFC 7627, DOI 10.17487/RFC7627, September 2015, 1077 . 1079 Authors' Addresses 1081 Kelsey Cairns 1082 Washington State University 1083 Pullman, WA 99164-2752 1084 USA 1086 Email: kcairns@wsu.edu 1088 John Mattsson 1089 Ericsson AB 1090 SE-164 80 Stockholm 1091 Sweden 1093 Email: john.mattsson@ericsson.com 1095 Robert Skog 1096 Ericsson AB 1097 SE-164 80 Stockholm 1098 Sweden 1100 Email: robert.skog@ericsson.com 1102 Daniel Migault 1103 Ericsson 1104 8400 boulevard Decarie 1105 Montreal, QC H4P 2N2 1106 Canada 1108 Phone: +1 514-452-2160 1109 Email: daniel.migault@ericsson.com