idnits 2.17.1 draft-mglt-lurk-tls12-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 350: '... the latter SHOULD happen over a sec...' RFC 2119 keyword, line 369: '... The server_random MUST follow the structure of [RFC5246] section...' RFC 2119 keyword, line 384: '... The operation MUST be performed by ...' RFC 2119 keyword, line 405: '... A LURK Client MAY use the rsa_maste...' RFC 2119 keyword, line 410: '... The LURK Client MUST ensure that the ...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 277 has weird spacing: '...rSecret pre_m...' == Line 290 has weird spacing: '...s_funct the o...' == Line 293 has weird spacing: '..._random the r...' == Line 314 has weird spacing: '...essages provi...' == Line 318 has weird spacing: '...inished the T...' == (15 more instances...) -- The document date (July 02, 2018) is 2118 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFD-TBD' is mentioned on line 943, but not defined == Missing Reference: 'RFC-TBD-LURK' is mentioned on line 951, but not defined == Missing Reference: 'RFC-TBD' is mentioned on line 976, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 1146, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 8017 == Outdated reference: A later version (-18) exists of draft-ietf-acme-acme-12 == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-03 == Outdated reference: A later version (-01) exists of draft-mglt-lurk-lurk-00 Summary: 5 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LURK D. Migault 3 Internet-Draft Ericsson 4 Intended status: Standards Track I. Boureanu 5 Expires: January 3, 2019 University of Surrey 6 July 02, 2018 8 LURK Extension version 1 for (D)TLS 1.2 Authentication 9 draft-mglt-lurk-tls12-01 11 Abstract 13 This document describes the LURK Extension 'tls12' which enables 14 interactions between a LURK Client and a LURK Server in a context of 15 authentication with (D)TLS 1.2. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 3, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 4 53 3. LURK Header . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. rsa_master, rsa_master_with_poh . . . . . . . . . . . . . . . 6 55 4.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 6 56 4.1.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . 8 57 4.2. Response Payload . . . . . . . . . . . . . . . . . . . . 9 58 4.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 10 59 4.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 10 60 5. rsa_extended_master, rss_extended_master_with_poh . . . . . . 11 61 5.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 11 62 5.2. Response Payload . . . . . . . . . . . . . . . . . . . . 12 63 5.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 12 64 5.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 12 65 6. ecdhe" . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 13 67 6.2. Response Payload . . . . . . . . . . . . . . . . . . . . 14 68 6.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 15 69 6.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 15 70 7. capabilities . . . . . . . . . . . . . . . . . . . . . . . . 15 71 7.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 16 72 7.2. Response Payload . . . . . . . . . . . . . . . . . . . . 16 73 7.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 17 74 7.4. LURK Server Behavior" . . . . . . . . . . . . . . . . . . 17 75 8. ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 8.1. Request Payload . . . . . . . . . . . . . . . . . . . . . 17 77 8.2. Response Payload . . . . . . . . . . . . . . . . . . . . 18 78 8.3. LURK Client Behavior . . . . . . . . . . . . . . . . . . 18 79 8.4. LURK Server Behavior . . . . . . . . . . . . . . . . . . 18 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 9.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 9.2. ECDHE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 9.3. Perfect Foward Secrecy . . . . . . . . . . . . . . . . . 20 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 86 12. Apendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 12.1. LURK Exchange for TLS RSA Extended Master Secret . . . . 24 88 12.2. LURK Exchange for TLS ECDHE Signature . . . . . . . . . 26 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 90 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 91 13.2. Informative References . . . . . . . . . . . . . . . . . 27 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 94 1. Introduction 96 This document describes the LURK Extension for TLS 1.2 so the LURK 97 Server can implement a Cryptographic Service in a TLS 1.2 [RFC5246] 98 and DTLS 1.2 [RFC6347] context. 100 More specifically, the LURK Server will be in charge of performing 101 the cryptographic operations associated to the private key of the TLS 102 Server, while other aspects of the termination of the TLS session is 103 handled by other services in the same administrative domain or in a 104 different administrative domain. Most Cryptographic Operations are 105 related to the TLS authentication and the current document limits the 106 Cryptographic Operations to the following authentication methods: RSA 107 and ECDHE_RSA defined in [RFC5246], [RFC6347] as well as ECDHE_ECDSA 108 defined in [I-D.ietf-tls-rfc4492bis]. 110 A more detailed description of some use cases foreseen in a TLS 111 context can be found in [I-D.mglt-lurk-tls-use-cases]. 113 HTTPS delegation has been the main concern of the Content Delivery 114 Networks Interconnection (cdni) Working Group and several mechanisms 115 have been designed to delegate the load from an upstream entity to a 116 downstream entity. Entities can be of different nature and may 117 designated differently according to the context. Typically 118 designations includes Content Owner, CDN Provider, Domain Name Owner 119 for example. [I-D.fieau-cdni-https-delegation] provides a details 120 comparison of the various mechanisms applies to the CDN 121 Interconnection, and the remaining of this section positions these 122 mechanisms at a very high level view. 124 STAR [I-D.ietf-acme-star], [I-D.sheffer-acme-star-request] describes 125 a methods where the domain name owner or the content owner 126 orchestrates the refreshing process between a CA and the CDN 127 (terminating the TLS session). The CDN refreshes regularly and 128 automatically its certificates using [I-D.ietf-acme-acme], which 129 allows the use of short term certificates. 131 Delegated credentials [I-D.rescorla-tls-subcerts] consists having a 132 certificate that enables the servers to generates some "delegated 133 credentials". 135 STAR and "delegated credentials" both require some changes performed 136 by the CA - new certificate type for the delegated credentials and 137 new interfaces for the delegated and delegating entity for STAR. In 138 both case the TLS Client authenticates the delegated entity. While 139 STAR does not require changes on the TLS Client, the "delegated 140 credential" solution does. In both cases, the delegation is 141 controlled by limiting in time (7 days), which is also the limit of 142 use of a stolen key or a rogue server. Such delegation provides a 143 high scalability of the architecture and prevents additional delays 144 when a TLS session is established. 146 The LURK Architecture [I-D.mglt-lurk-lurk] and the LURK Extension 147 'tls12' do not proceed to the delegation of the HTTPS delegation by 148 delegating the entire TLS termination. Instead, the TLS termination 149 is split into sub services, for example one associated to the 150 networking part and one associated to the cryptographic operation. 151 While micro services associated to the networking part are delegated, 152 the micro service associated to the cryptographic operation may not 153 be delegated. As a result, LURK Architecture is focused on the 154 protection of the Cryptographic Material and prevents leakage of the 155 Cryptographic Material for example by avoiding node exposed to the 156 Internet to host the Cryptographic Material. In addition, LURK 157 provides means to instantaneously suspend the delegation with a 158 suspicious node. On the other hand the LURK Extension 'tls12' 159 introduces some latency, and is not as scalable as STAR or delegated 160 credential solutions. 162 The LURK Extension 'tls12' is seen as a complementary to the STAR and 163 "delegated credentials". The LURK Extension 'tls12' is a backend 164 solution that does not require any modifications from TLS Client or 165 the CA. It is also aimed at protecting the Cryptographic Material. 167 170 LURK may also be deployed within an administrative domain in order to 171 to provide a more controlled deployment of TLS Servers. 173 2. Terminology and Acronyms 175 This document re-uses the terminology defined in 176 [I-D.mglt-lurk-lurk]. 178 3. LURK Header 180 LURK / TLS 1.2 is a LURK Extension that introduces a new designation 181 "tls12". This document assumes that Extension is defined with 182 designation set to "tls12" and version set to 1. The LURK Extension 183 extends the LURKHeader structure defined in [I-D.mglt-lurk-lurk] as 184 follows: 186 enum { 187 tls12 (1), (255) 188 } Designation; 190 enum { 191 capabilities (0), ping (1), rsa_master (2), 192 rsa_extended_master (3), ecdhe (4), (255) 193 }TLS12Type; 195 enum { 196 // generic values reserved or aligned with the 197 // LURK Protocol 198 request (0), success (1), undefined_error (2), 199 invalid_payload_format (3), 201 // code points for rsa authentication 202 invalid_key_id_type (4), invalid_key_id (5), 203 invalid_tls_random (6), invalid_prf (7), 204 invalid_encrypted_premaster (8), invalid_finished (9) 206 //code points for ecdhe authentication 207 invalid_ec_type (10), invalid_ec_curve (11), 208 invalid_poo_prf (12), invalid_poo (13), (255) 209 }TLS12Status 211 struct { 212 Designation designation = "tls12"; 213 int8 version = 1; 214 } Extension; 216 struct { 217 Extension extension; 218 select( Extension ){ 219 case ("tls12", 1): 220 TLS12Type; 221 } type; 222 select( Extension ){ 223 case ("tls12", 1): 224 TLS12Status; 225 } status; 226 uint64 id; 227 unint32 length; 228 } LURKHeader; 230 4. rsa_master, rsa_master_with_poh 232 An exchange of type "rsa_master" or "rsa_master_with_poh" enables the 233 LURK Client to delegate the RSA Key Exchange and authentication as 234 defined in [RFC5246]. The LURK Server returns the master secret. 236 "rsa_master" provides the necessary parameters and details to 237 generate the master secret, as well as to hinder replaying of old 238 handshake messages by a corrupt LURK Client. I.e., some attestation 239 of message-freshness is acquired by the LURK Server. 241 In addition, the"rsa_master_with_poh" provides a proof of handshake 242 (PoH). The proof of handshake consists in providing the Finished 243 message of the TLS Client to the LURK Server, so that latter can 244 perform more checks that in the "rsa_master" mode. Notably, herein, 245 the LURK Server also checks that the LURK request is performed in a 246 context of a TLS handshake. 248 While "rsa_master" and "rsa_master_with_poh" exchange have 249 respectively different requests, the response is the same. The 250 motivation for having different type is that the parameters provided 251 to the LURK Server are provided using different format. "rsa_master" 252 provides them explicitly, while "rsa_master_with_poh" provides them 253 via handshake messages. 255 4.1. Request Payload 257 A rsa_master request payload has the following structure: 259 enum { 260 sha256_32 (0), (255) 261 }KeyPairIdType; 263 struct { 264 KeyPairIdType type; 265 opaque data; // length defined by the type 266 } KeyPairID; 268 enum{ 269 sha256 (0), (255) 270 } PFSAlgorithm 272 struct { 273 KeyPairID key_id; 274 PFSAlgorithm freshness_funct; 275 Random client_random; // see RFC5246 section 7.4.1.2 276 Random server_random; 277 EncryptedPreMasterSecret pre_master; 278 // see RFC5246 section 7.4.7.1 279 // Length depends on the key. 280 } 281 } TLS12RSAMasterRequestPayload; 283 key_id The identifier of the public key. This document defines 284 sha256_32 format which takes the 32 first bits of the hash of the 285 binary ASN.1 DER representation of the public key using sha256. 286 The binary representation of RSA keys is described in [RFC8017]. 287 The binary representation of ECC keys is the subjectPublicKeyInfo 288 structure defined in [RFC5480]. 290 freshness_funct the one-way hash function (OWHF) used by LURK to 291 implement Perfect Forward Secrecy. 293 client_random the random value associated to the TLS Client as 294 defined in [RFC5246] Section 7.4.1.2. 296 server_random: the random value associated to the TLS Server as 297 defined in [RFC5246] Section 7.4.1.2. 299 EncryptedPreMasterSecret : The encrypted master secret as defined in 300 [RFC5246] Section 7.4.7.1. 302 A rsa_master_with_poh request payload has the following structure: 304 struct { 305 KeyPairID key_id; 306 PFSAlgorithm freshness_funct; 307 opaque handshake_messages<2...2^16-2> 308 // see RFC5246 section 7.4.9 309 Finished finished 310 } TLS12RSAMasterWithPoHRequestPayload; 312 key_id, freshness_funct are defined above 314 handshake_messages provides the necessary handshake messages to 315 compute the Finished message of the TLS Client as defined in 316 [RFC5246] section 7.4.9. 318 finished the TLS Client Finished message as defined by {{!RFC5246} 319 section 7.4.9. 321 4.1.1. Perfect Forward Secrecy 323 This document defines a mechanism which uses a function called 324 freshness_funct, to prevent an attacker to send a request to the LURK 325 Server in such a way that the said attacker can obtain back the 326 mastersecret for an old handshake. In other words, the use of this 327 function helps prevent a forward-secrecy attack on an old TLS 328 session, where the attack would make use that session's handshake- 329 data observed by the adversary. 331 This design achieves PFS with freshness_funct being a collision- 332 resistant hash function (CHRF). By CRHF, we mean a one-way hash 333 function (OWHF) which also has collision resistance; the latter means 334 that it is computationally infeasible to find any two inputs x1 and 335 x2 such that freshness_funct(x1) = freshness_funct(x2). By one-way 336 hash function (OWHF) we mean, as standard, a hash function 337 freshness_funct that satisfies preimage resistance and 2nd-preimage 338 resistance. That is, given a hash value y, it is computationally 339 infeasible to find an x such that freshness_funct(x) = y, and 340 respectively- given a value x1 and its hash freshness_funct(x1), it 341 is computationally infeasible to find another x2 such that 342 freshness_funct(x2) = freshness_funct(x1). 344 For the concrete use of our freshness_funct funtions, let S be a 345 fresh, randomly picked value generated by the LURK Client. The value 346 of server_random in the TLS exchange is then equal to 347 freshness_funct(S), i.e., server_random=freshness_funct(S). Between 348 the TLS Client and the LURK Server only server-random is exchanged. 349 The LURK Client sends S to the Key Server, in the query. Note that 350 the latter SHOULD happen over a secure channel. 352 A man-in-the-middle attacker observing the (plaintext) TLS handshake 353 between a TLS Client and the LURK Client does not see S, but only 354 server_random. The preimage resistance guaranted by the 355 freshness_funct makes it such that this man-in-the-middle cannot 356 retrieve S out of the observed server-random. As such, this man-in- 357 the-middle attacker cannot query the S corresponding to an (old) 358 observed handshake to the Key Server. Moreover, the collision 359 resistance guaranteed by the freshness_funct makes it such that if 360 the aforementioned man-in-the-middle cannot find S' such that 361 freshness_funct(S)=freshness_funct(S'). 363 As discussed in Section 9, PFS may be achieved in other ways (i.e., 364 not using a CRHF and the aforementioned exchanges but other 365 cryptographic primitives and other exchanges). These may offer 366 better computational efficiency. These may be standardized in future 367 versions of the LURK extension "tls12. 369 The server_random MUST follow the structure of [RFC5246] section 370 7.4.1.2, which carries the gmt_unix_time in the first four bytes. 371 So, the ServerHello.random of the TLS exchange is derived from the 372 server_random of the LURK exchange as defined below: 374 gmt_unix_time = server_random[0..3]; 375 ServerHello.random = freshness_funct( server_random + "tls12 pfs" ); 376 ServerHello.random[0..3] = gmt_unix_time; 378 384 The operation MUST be performed by the LURK Server as well as the TLS 385 Server, upon receiving the master secret or the signature of the 386 ecdhe_params from the LURK Client. 388 4.2. Response Payload 390 The "rsa_master" response payload contains the master secret and has 391 the following structure: 393 struct { 394 opaque master[0..47]; 395 } TLS12RSAMasterResponsePayload; 397 4.3. LURK Client Behavior 399 A LURK Client initiates an rsa_master or an rsa_master_with_poh 400 exchange in order to retrieve the master secret. The LURK exchange 401 happens on the TLS Server side (Edge Server). Upon receipt of the 402 master_secret the Edge Server generates the session keys and finish 403 the TLS key exchange protocol. 405 A LURK Client MAY use the rsa_master_with_poh to provide the LURK 406 Server evidences that the LURK exchange is performed in the context 407 of a TLS handshake. The Proof of TLS Hanshake (POH) helps the LURK 408 Server to audit the context associated to the query. 410 The LURK Client MUST ensure that the transmitted values for 411 server_random is S such as server_random = freshness_funct( S ). 413 4.4. LURK Server Behavior 415 Upon receipt of a rsa_master or a rsa_master_with_poh request, the 416 LURK Server proceeds according to the following steps: 418 1. The LURK Server checks the RSA key pair is available (key_id). 419 If the format of the key pair identifier is not understood, an 420 "invalid_key_id_type" error is returned. If the designated key 421 pair is not available an "invalid_key_id" error is returned. 423 2. The LURK Server checks the freshness_funct. If it does not 424 support the PFSAlgorithm, an "invalid_prf" error is returned. 426 3. The LURK Server collects the client_random, server_random and 427 pre_master parameters either provided explicitly (rsa_master) or 428 within the handshake (rsa_master_with_poh). 430 4. The LURK Server MUST check the format of the server_random and 431 more specifically checks the gmt_unix_time associated to the 432 random is acceptable. Otherwise it SHOULD return an 433 "invalid_tls_random" error. The value of the time window is 434 implementation dependent and SHOULD be a configurable 435 parameters. The LURK Server MAY also check the client_random. 436 This should be considered cautiously as such check may prevent 437 TLS Clients to set a TLS session. client_random is generated by 438 the TLS Client whose clock might not be synchronized with the 439 one of the LURK Server or that might have a TLS implementations 440 that does not generate random based on gmt_unix_time. 442 5. The LURK Server computes the necessary ServerHello.random from 443 the server_random when applicable as described in Section 4.1.1. 445 When option is set to "finished" the ServerHello.random in the 446 handshake is replaced by its new value. 448 6. The LURK Server checks the length of the encrypted premaster 449 secret and returns an "invalid_payload_format" error if the 450 length differs from the length of binary representation of the 451 RSA modulus. 453 7. The LURK Server decrypts the encrypted premaster secret as 454 described in [RFC5246] section 7.4.7.1. When a PKCS1.5 format 455 error is detected, or a mismatch between the TLS versions 456 provided as input and the one indicated in the encrypted 457 premaster secret, the Key Server returns a randomly generated 458 master secret. 460 8. The LURK Server generates the master secret as described in 461 [RFC5246] section 8.1 using the client_random, and the 462 server_random provided by the LURK Client. 464 9. With a rsa_master_with_poh, the LURK Server checks the Finished 465 message is checked as defined in [RFC5246] section 7.4.9. In 466 case of mismatch returns an "invalid_finished" error. 468 10. The LURK Server returns a master secret in a 469 TLS12RSAMasterResponsePayload. 471 11. Error are expected to provide the LURK Client an indication of 472 the cause that resulted in the error. When an error occurs the 473 LURK Server MAY ignore the request, or provide more generic 474 error codes such as "undefined_error" or "invalid_format". 476 5. rsa_extended_master, rss_extended_master_with_poh 478 A exchange of type "rsa_extended_master" enables the LURK Client to 479 delegate the RSA Key Exchange and authentication. The LURK Server 480 returns the extended master secret as defined in [RFC7627]. 482 5.1. Request Payload 484 The "rsa_extended_master" request has the following structure: 486 enum { sha256 (0), (255) } PRFAlgorithm 488 enum { null(0), sha256_128(1), sha256_256(2), 489 (255) }POOPRF 491 struct { 492 KeyPairID key_id 493 PFSAlgorithm freshness_funct // see RFC5246 section 6.1 494 opaque handshake_messages<2...2^16-2> 495 // see RFC7627 section 4 496 }TLS12ExtendedMasterRSARequestPayload; 498 The "rsa_extended_master_with_poh" request has the following 499 structure: 501 struct { 502 KeyPairID key_id 503 PFSAlgorithm freshness_funct // see RFC5246 section 6.1 504 opaque handshake_messages<2...2^16-2> 505 // see RFC5246 section 7.4.9 506 Finished finished 507 } 508 }TLS12ExtendedMasterRSAWithPoHRequestPayload; 510 key_id, freshness_funct, option, handshake, finished are defined in 511 Section 4.1. 513 handshake_messages With a the handshake message includes are those 514 necessary to generate a extended master secret as defined in 515 [RFC7627] section 4. 517 5.2. Response Payload 519 rsa_extended_master response payload has a similar structure as the 520 rsa_master response payload Section 4.2. 522 5.3. LURK Client Behavior 524 The LURK Client proceeds as described in {{sec-rsa-master-clt}. The 525 main difference is that the necessary element to generate the master 526 secret are included in the handshake and or not provided separately. 528 5.4. LURK Server Behavior 530 The LURK Server proceeds as described in Section 4.4 except that the 531 generation of the extended master is processed as described in 532 [RFC7627]. 534 6. ecdhe" 536 A exchange of type "ecdhe" enables the LURK Client to delegate the 537 ECDHE_RSA [RFC5246] or the ECDHE_ECDSA [I-D.ietf-tls-rfc4492bis] 538 authentication. 540 6.1. Request Payload 542 The "ecdhe" request payload has the following structure: 544 enum { null(0), sha256_128(1), sha256_256(2), 545 (255) }POOPRF 547 struct { 548 POOPRF poo_prf; 549 select( poo_prf) { 550 case ( "null" ): 551 case ( "sha256_128" or "sha256_256" ): 552 ECPoint rG; //I-D.ietf-tls-rfc4492bis section 5.4 553 ECPoint tG; 554 } 555 } TLS12POOParams; 557 struct { 558 KeyPairID key_id; 559 PRFAlgorithm freshness_funct; 560 Random client_random; // see RFC5246 section 7.4.1.2 561 Random server_random; 562 SignatureAndHashAlgorithm sig_and_hash //RFC 5246 section 4.7 563 ServerECDHParams ecdhe_params; // I-D.ietf-tls-rfc4492bis section 5.4 564 POOParams poo_params; 565 } TLS12ECDHERequestPayload; 567 key_id, freshness_funct, client_random, server_random is defined in 568 Section 4.1. 570 ecdhe_params contains as defined in [I-D.ietf-tls-rfc4492bis] 571 section 5.4, the elliptic curve domain parameters associated with 572 the ECDH public key (defined by the ECParameters structure) and 573 the ephemeral ECDH public key (defined by the ECPoint structure). 574 The public key is also noted in this document bG with b is a 575 random secret generated by the LURK Client and G the base point of 576 the curve. 578 poo_params defines the necessary parameters to provide a proof of 579 ownership of the ECDHE private key. This option is intended to 580 prevent the LURK Server to sign bytes that do not correspond to a 581 ECDHE public key. 583 poo_prf pseudo random function used to generate the necessary 584 randoms to proof ownership of the private key. This document 585 defines sha256_128 and sha256_256 which apply the sha256 hash 586 function and respectively return the 128 or 256 first bits of the 587 resulting hash. 589 rG, tG are necessary points to generate the proof of ownership. r is 590 a random number chosen by the LURK Client. G is the the base 591 point of the curve. t = cb + r, with c a number that is not under 592 the control of the LURK Client generated as the output of poo_prf 593 and b the random secret of the private key. 595 The proof of ownership consists in the LURK Client proving the 596 knowledge of the private random b, while not disclosing b. 598 c MUST NOT be under the control of the LURK Client. To achieve that 599 goal, c is generated as described below: 601 c = poo_prf ( base + ecdhe_params + "tls12 poo") 603 The LURK Client computes t = cb + r and sends rG, tG, in poo_params 604 and bG in the ecdhe_params 606 The LURK Server computes c(bG) + rG and compares the output with tG. 607 The equality proves the ownership of b by the LURK Client. 609 Note r and c may be treated as "very short-term secrets" but MUST 610 remain non-predictable. It is RECOMMENDED to use a length equivalent 611 to the expected level of security, that is 128 bit length (resp. 256 612 bit length) for a 128 (resp 256) bit security level. Given b, we 613 RECOMMEND r and c to be at least half the size of b. 615 6.2. Response Payload 617 The "ecdhe" response payload has the following structure: 619 struct { 620 Signature signed_params; // I-D.ietf-tls-rfc4492bis section 5.4 621 } TLS12ECDHEResponsePayload; 623 signed_params signature applied to the hash of the ecdhe_params as 624 well as client_random and server_random as described in 625 [I-D.ietf-tls-rfc4492bis] section 5.4. 627 6.3. LURK Client Behavior 629 The LURK Client builds the base as described in Section 4.1. The 630 LURK Client computes c, t, rG and tG as described in Section 6.1. 632 Upon receiving the response payload, the LURK Client MAY check the 633 signature. If the signature does not match an error SHOULD be 634 reported. 636 6.4. LURK Server Behavior 638 Upon receiving an ecdhe request, the LURK Server proceeds as follows: 640 1. perform steps 1 - 6 as described in Section 4.4 642 2. The LURK Server performs some format check of the ecdhe_params 643 before signing them. If the ecdhe_params does not follow the 644 expected structure. With the notations from 645 [I-D.ietf-tls-rfc4492bis], if curve_type is not set to 646 "named_curve", the LURK Server SHOULD respond with an 647 "invalid_ec_type" error. If the curve or namedcurve is not 648 supported the LURK Server SHOULD be able to respond with an 649 "invalid_ec_curve" error. 651 3. The LURK Server processes the poo_params. If the poo_prf is not 652 supported, the LURK Extension returns a "invalid_poo_prf" status. 653 If poo_prf is supported and different from "null", the LURK 654 Server proceeds to the proof of ownership as described in 655 Section 6.1. If the proof is not properly verified, the LURK 656 Extension returns a "invalid_poo" status. 658 4. The LURK Server processes the base structure as described in 659 Section 4.4 661 5. The LURK Server generates the signed_params. 663 Error are expected to provide the LURK Client an indication of the 664 cause that resulted in the error. When an error occurs the LURK 665 Server MAY ignore the request, or provide more generic error codes 666 such as "undefined_error" or "invalid_format". 668 7. capabilities 670 A exchange of type "capabilities" enables the LURK Client to be 671 informed of the supported operations performed by the LURK Server. 672 The supported parameters are provided on a per type basis. 674 7.1. Request Payload 676 A LURK "capabilities" request has no payload. 678 7.2. Response Payload 680 The "capabilities" response payload lists for each supported type, 681 the supported certificates, the supported signatures and hash 682 associated. The "capabilities" payload has the following structure: 684 struct { 685 KeyPairID key_id_type_list<0..255>; 686 PFSAlgorithmList freshness_funct_list<0..255> 687 OptionList option_list<0..255> 688 Certificate certificate_list 689 } TLS12RSACapability; 691 struct { 692 TLS12RSACapability rsa_cap; 693 SignatureAndHashAlgorithm sig_and_hash_list<0..255> 694 NameCurve ecdsa_curves_list<0..255>; 695 NameCurve ecdhe_curves_list<0..255> 696 POOPRF poo_prf_list<0..255> 697 } TLS12ECDHECapability; 699 struct { 700 uint32 length; 701 TLS12Type type 702 Select( type ) { 703 case rsa_master : TLS12RSACapability, 704 case rsa_extended_master : TLS12RSACapability, 705 case ecdhe : TLS12ECDHECapability 706 } capability ; 707 } TLS12Capability 709 struct { 710 TLS12Capability capability_list; 711 opaque state<32>; 712 } TLS12CapabilitiesResponsePayload; 714 key_id_type_list the supported key_id_type. 716 freshness_funct_list designates the list of freshness_funct ( see 717 Section 4.1). 719 certificate_list designates the certificates associated to message 720 type. The format is defined in [I-D.ietf-tls-tls13] in section 721 4.4.2. This format enables the use of X509 as well as Raw Public 722 key, while the Certificate structure defined in [RFC5246] section 723 7.4.2 does not. 725 sig_and_hash_list designates supported signature algorithms as well 726 as PRF used for the different operations. The format is defined 727 in [RFC5246] section 7.4.1.4.1. 729 ecdsa_curves_list the supported signatures 731 ecdhe_curves_list the supported curves for ECHDE parameters. 733 poo_prf_list the supported message type poo_prf ( see Section 6.1. 734 to be used with the proof of ownership. 736 type_list the supported message type of the LURK extension. 738 state characterizes the configuration associated to 'tls12' on the 739 LURK Server.. 741 7.3. LURK Client Behavior 743 The LURK Client performs a capability request in order to determine 744 the possible operations. 746 The LURK Client is expected to keep the state value to be able to 747 detect a change in the LURK Server configuration when an error 748 occurs. 750 7.4. LURK Server Behavior" 752 Upon receiving a capabilities request, the LURK Extension MUST return 753 the capabilities payload associated to a "success" status to the LURK 754 Server. These information are then forwarded by the LURK Server to 755 the LURK Client. 757 8. ping 759 A exchange of type "ping" enables the LURK Client to check the 760 reachability in a context of the defined LURK Extension. 762 8.1. Request Payload 764 A "ping" request has no payload. 766 8.2. Response Payload 768 A "ping" response has no payload. 770 8.3. LURK Client Behavior 772 The LURK Client sends a "ping" request to test the reachability of 773 the LURK Server. The reachability is performed for the tls12 LURK 774 Extension. 776 8.4. LURK Server Behavior 778 Upon receiving a ping request, the LURK Extension MUST return the 779 ping response associated with a "success" status to the LURK Server. 780 These information are then forwarded by the LURK Server to the LURK 781 Client. 783 9. Security Considerations 785 The security considerations defined in [I-D.mglt-lurk-lurk] applies 786 to the LURK Extension "tls12" defined in this document. 788 Anti-replay mechanisms rely in part on the security of channel 789 between the LURK Client and the LURK Server. As such the channel 790 between the LURK Client and the LURK Server MUST be ensuring 791 confidentiality and integrity. More specifically, the exchanges 792 between the LURK Client and the LURK Server MUST be an encrypted with 793 authentication encryption, and the two parties had previously 794 mutually authenticated. 796 The LURK Extension "tls12" is expected to have response smaller that 797 the request or at least not significantly larger, which makes "tls12" 798 relatively robust to amplification attacks. This is especially 799 matters when LURK is using UDP. The use of an authenticated channel 800 reduces also the risk of amplification attacks even when UDP is being 801 used. 803 The LURK Client and the LURK Server use time in their way to generate 804 the server_random. Care MUST be taken so the LURK Client and LURK 805 Server remain synchronized. 807 9.1. RSA 809 The rsa_master and rsa_extended_master returns the master_secret 810 instead of the premaster. The additional hashing operation necessary 811 to generate the master secret is expected to improve the protection 812 of the RSA private key against cryptographic analysis based on the 813 observation of a set of clear text and corresponding encrypted text. 815 The standard TLS1.2 is robust against Bleichenbacher attack as it 816 provides no means to detect if the error comes from a TLS version 817 mismatch or from the premaster format. This properties remain with 818 LURK, and so LURK does not present vulnerabilities toward 819 Bleichenbacher attack, and cannot be used as a decryption oracle. 821 9.2. ECDHE 823 A passive attacker observing the ecdhe exchange may collect a 824 sufficient amount of clear text and corresponding signature to 825 perform a cryptographic analysis or to reuse the signature for other 826 purposes. As a result, it remains important to encrypt the ecdhe 827 exchange between the LURK Client and the LURK Server. Note that this 828 vulnerability is present in TLS 1.2 as a TLS Client can accumulate 829 these data as well. The difference with LURK is by listening the 830 LURK Server, the accumulation is achieved for all TLS Clients. 832 As previously mentioned, the LURK Server may be used as signing 833 oracle for the specific string: 835 SHA(ClientHello.random + ServerHello.random + 836 ServerKeyExchange.params); 838 More specifically, the ECDHE_RSA and ECDHE_DSA mechanisms does not 839 associate the signature to a TLS1.2 context. As a result, an 840 attacker could re-used the signature in another context. 842 The attack may operate by collecting a large collection of clear text 843 and their corresponding signature. When the attacker want to provide 844 a signature, it checks in its database, a match occurs between the 845 two contents to be signed. The probability of a collision increases 846 with number of available hashes. The attack is related the pre-image 847 and collision resistance properties of the hash function. 849 The attacker may also given a clear text to be signed, generate a 850 collision such that a collision occurs which provides is related to 851 the second pre-image and collision resistance property of the hash 852 function. 854 The surface of attack is limited by: 856 o limiting the possibility of aggregating a collection of clear text 857 and their corresponding signatures. This could be achieved by 858 using multiple LURK Clients using an encrypted channel between the 859 LURK Client and the LURK Server. 861 o increasing the checks and ensure that signature is performed in a 862 TLS 1.2 context. For that purpose it is RECOMMENDED the LURK 863 Server checks the consistency of its input parameters. This 864 includes the proof of ownership as well as the format of the 865 randoms and ecdhe_params for example. 867 o limiting the usage of a Cryptographic material to a single usage, 868 in our case serving TLS 1.2. 870 9.3. Perfect Foward Secrecy 872 This document uses sha256 as the freshness_funct, in order to achieve 873 PFS Section 4.1.1 as described above. By construction of the 874 server_random, of the output of freshness_funct we will keep only the 875 last 28 bytes. The PFS property is in place as long as this 876 truncated version of freshness_funct can be considered a CRHF and 877 that the 28 bytes of randomness carried by the server_random are 878 sufficient. Otherwise, the mechanism described in this document will 879 not be considered as safe. 881 Details on the truncation will be added. Alternatively, we could use 882 a hash function like SHA3 (or, more explicitly SHAKE) which considers 883 variable output length as part of its design. The SHAKE functions 884 allow arbitrary output lengths and the PFS-input S can be of 885 arbitrary length too. However, for SHAKE128-d, if the truncated 886 output is of length d as low as 224 bits (28 bytes), then one only 887 gets 224/2=112 bits security w.r.t. collision-resistance, > 112 bits 888 w.r.t. preimage resistance and 112 bits security w.r.t. second 889 preimage resistance. 891 One reason why we have the hash-based solution to is to reduce 892 communication costs between the LURK Client and the LURK Server, 893 whilst still getting more than some security w.r.t. a MiM corrupting 894 a LURK Client and then attempting a PFS attack. 896 But, if we disregard the overhaed on communication costs, we can 897 consider other mechanisms not based on CRHF for attaining PFS 898 security. See I and II below. 900 I. For example, as freshness_funct, one can use an instance of a 901 pseudo random function (PRF), keyed on a key K that the LURK Server 902 already shares with the LURK Client. I.e., 903 server_random=freshness_funct(S;K). In this case, the mechanisms to 904 achieve PFS are as follows: 1. The LURK Client and the LURK Server 905 run a key-establishment protocol before every LURK session to 906 establish such a new key K for every LURK session. Alternatively, 907 the export this key of the key-establishment run to secure the 908 channel. The time-to-live of K is one session only. 2. The LURK 909 Server generates the value S on its side and send the server_random 910 to the LURK Client. 3. The LURK Client uses this server_random with 911 the TLS Client 4. The LURK Server checks the correctness of the use 912 of the said server_random when the query for the master_secret is 913 made, with the messages forwarded therein; 915 II. In fact, since the channel between the LURK Client and the LURK 916 Server MUST be encrypted by default, all for 2 steps in point I above 917 can be combined into 1 step (without the need of a specially executed 918 key-establishment): a. the LURK Server sends the server_random to 919 the LURK Client. b. the LURK Client uses this server_random with 920 the TLS Client c. the LURK Server checks the correctness of the use 921 of the said server_random when the query for the master_secret is 922 made, with the messages forwarded therein; 924 Yet, option I and option II are more expensive on the communication 925 than the version achieving PFS with a hash function. I.e., in I and 926 II, the LURK Server needs to be involved on the first part of the TLS 927 handshake to produce the S or server_random for the LURK Client. 928 However, note that the LURK Client no longer queries S, hence the 929 risk of a man-in-the-middle querying an old S is eliminated by 930 design. 932 Option II above is akin to what "Content delivery over TLS: a 933 cryptographic analysis of keyless SSL," by K. Bhargavan, I. 934 Boureanu, P. A. Fouque, C. Onete and B. Richard at 2017 IEEE 935 European Symposium on Security and Privacy (EuroS&P), Paris, 2017, 936 pp. 1-16, suggested in order to amend (forward-secrecy) attacks on 937 Keyless SSL. 939 10. IANA Considerations 941 The requested information is defined in [I-D.mglt-lurk-lurk]. 943 LURK Extension Designation: tls12 LURK Extension Reference: [RFD-TBD] 944 LURK Extension Description: RSA, ECDHE_RSA and ECDHE_ECDSA for (D)TLS 945 1.2. 947 LURK tls12 Extension Status 949 Value Description Reference 950 --------------------------------------------------- 951 0 - 1 Reserved [RFC-TBD-LURK] 952 2 undefined_error [RFC-TBD] 953 3 invalid_payload_format [RFC-TBD] 954 4 invalid_key_id_type [RFC-TBD] 955 5 invalid_key_id [RFC-TBD] 956 6 invalid_tls_random [RFC-TBD] 957 7 invalid_prf [RFC-TBD] 958 8 invalid_encrypted_premaster [RFC-TBD] 959 9 invalid_finished [RFC-TBD] 960 10 invalid_ec_type [RFC-TBD] 961 11 invalid_ec_curve [RFC-TBD] 962 12 invalid_poo_prf [RFC-TBD] 963 13 invalid_poo [RFC-TBD] 964 14 - 255 UNASSIGNED 966 LURK tls12 Extension Type 968 Value Description Reference 969 ---------------------------------------------- 970 0 capabilities [RFC-TBD] 971 1 ping [RFC-TBD] 972 2 rsa_master [RFC-TBD] 973 2 rsa_master_with_poh [RFC-TBD] 974 3 rsa_extended_master [RFC-TBD] 975 3 rsa_extended_master_with_poh [RFC-TBD] 976 4 ecdhe [RFC-TBD] 977 16 - 255 UNASSIGNED 979 11. Acknowledgments 981 We would like to thank for their very useful feed backs: Yaron 982 Sheffer, Yoav Nir, Stephen Farrell, Eric Burger, Thomas Fossati, Eric 983 Rescorla Mat Naslung, Rich Salz. Many ideas in this document are 984 from [I-D.erb-lurk-rsalg]. 986 We would also like to thank those that have supported LURK or raised 987 interesting discussions. This includes among others Robert Skog, 988 Hans Spaak, Salvatore Loreto, John Mattsson, Alexei Tumarkin, Yaron 989 Sheffer, Richard Brunner, Stephane Dault, Dan Kahn Gillmor, Joe 990 Hildebrand, Kelsey Cairns. 992 12. Apendix 994 ## LURK Exchange for TLS RSA Master Secret 996 TLS Client Edge Server Key Server 998 ClientHello 999 server_version 1000 client_random 1001 cipher_suite 1002 TLS_RSA_*, ... 1003 --------> 1004 S = server_random 1005 server_random = freshness_funct( S ) 1007 ServerHello 1008 tls_version 1009 server_random 1010 Cipher_suite=TLS_RSA 1011 Certificate 1012 RSA Public Key 1013 ServerHelloDone 1014 <-------- 1016 ClientKeyExchange 1017 EncryptedPremasterSecret 1018 [ChangeCipherSpec] 1019 Finished 1020 --------> 1022 TLS12 Request Header 1023 TLS12MasterRSARequestPayload 1024 key_id 1025 client_random 1026 S 1027 freshness_funct 1028 EncryptedPremasterSecret 1029 --------> 1031 server_random = freshness_funct( S ) 1033 master_secret = PRF(\ 1034 pre_master_secret + \ 1035 "master secret" +\ 1036 client_random +\ 1037 server_random)[0..47]; 1038 TLS12 Response Header 1039 TLS12MasterResponsePayload 1040 master 1041 <-------- 1043 [ChangeCipherSpec] 1044 Finished 1045 <-------- 1046 Application Data <-------> Application Data 1048 12.1. LURK Exchange for TLS RSA Extended Master Secret 1049 TLS Client Edge Server Key Server 1051 ClientHello 1052 tls_version 1053 cipher_suite 1054 TLS_RSA_*, ... 1055 Extension 0x0017 1056 --------> 1058 ServerHello 1059 edge_server_version 1060 cipher_suite=TLS_RSA 1061 Extension 0x0017 1062 Certificate 1063 RSA Public Key 1064 ServerHelloDone 1065 <-------- 1066 ClientKeyExchange 1067 EncryptedPremasterSecret 1068 [ChangeCipherSpec] 1069 Finished 1070 --------> 1072 TLS12 Request Header 1073 TLS12ExtendedMasterRSAInputPayload 1074 key_id 1075 tls_version 1076 master_prf 1077 session_hash 1078 EncryptedPreMasterSecret 1079 --------> 1081 1. Computing Master Secret 1082 master_secret = master_prf( 1083 pre_master_secret +\ 1084 "extended master secret" +\ 1085 session_hash)[0..47] 1087 TLS12 Response Header 1088 TLS12MasterPayload 1089 master 1090 <-------- 1092 [ChangeCipherSpec] 1093 Finished 1094 <-------- 1095 Application Data <-------> Application Data 1097 12.2. LURK Exchange for TLS ECDHE Signature 1099 TLS Client Edge Server Key Server 1101 ClientHello 1102 tls_version 1103 client_random 1104 cipher_suite 1105 TLS_ECDHE_ECDSA_*, TLS_ECDHE_RSA_*, ... 1106 Extension Supported EC, Supported Point Format 1107 --------> 1108 S = server_random 1109 server_random = freshness_funct( S ) 1111 TLS12 Request Header 1112 TLS12ECDHEInputPayload 1113 key_id 1114 client_random 1115 S 1116 ecdhe_params 1117 --------> 1118 server_random = freshness_funct( S ) 1120 signature = ECDSA( client_random +\ 1121 server_random + ecdhe_params ) 1123 TLS12 Response Header 1124 TLS12DigitallySignedPayloads 1125 signature 1126 <-------- 1128 ServerHello 1129 tls_version 1130 server_random 1131 Cipher_suite=TLS_ECDHE_ECDSA 1132 Extension Supported EC, 1133 Supported Point Format 1134 Certificate 1135 ECDSA Public Key 1136 ServerKeyExchange 1137 ecdhe_params 1138 signature 1139 ServerHelloDone 1140 <-------- 1142 ClientKeyExchange 1143 [ChangeCipherSpec] 1144 Finished 1145 --------> 1146 [ChangeCipherSpec] 1147 Finished 1148 <-------- 1149 Application Data <-------> Application Data 1151 13. References 1153 13.1. Normative References 1155 [I-D.ietf-tls-rfc4492bis] 1156 Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 1157 Curve Cryptography (ECC) Cipher Suites for Transport Layer 1158 Security (TLS) Versions 1.2 and Earlier", draft-ietf-tls- 1159 rfc4492bis-17 (work in progress), May 2017. 1161 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1162 (TLS) Protocol Version 1.2", RFC 5246, 1163 DOI 10.17487/RFC5246, August 2008, 1164 . 1166 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1167 "Elliptic Curve Cryptography Subject Public Key 1168 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1169 . 1171 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1172 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1173 January 2012, . 1175 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 1176 Langley, A., and M. Ray, "Transport Layer Security (TLS) 1177 Session Hash and Extended Master Secret Extension", 1178 RFC 7627, DOI 10.17487/RFC7627, September 2015, 1179 . 1181 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 1182 "PKCS #1: RSA Cryptography Specifications Version 2.2", 1183 RFC 8017, DOI 10.17487/RFC8017, November 2016, 1184 . 1186 13.2. Informative References 1188 [I-D.erb-lurk-rsalg] 1189 Erb, S. and R. Salz, "A PFS-preserving protocol for LURK", 1190 draft-erb-lurk-rsalg-01 (work in progress), May 2016. 1192 [I-D.fieau-cdni-https-delegation] 1193 Fieau, F., Emile, S., and S. Mishra, "HTTPS delegation in 1194 CDNI", draft-fieau-cdni-https-delegation-02 (work in 1195 progress), July 2017. 1197 [I-D.ietf-acme-acme] 1198 Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1199 Kasten, "Automatic Certificate Management Environment 1200 (ACME)", draft-ietf-acme-acme-12 (work in progress), April 1201 2018. 1203 [I-D.ietf-acme-star] 1204 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 1205 Fossati, "Support for Short-Term, Automatically-Renewed 1206 (STAR) Certificates in Automated Certificate Management 1207 Environment (ACME)", draft-ietf-acme-star-03 (work in 1208 progress), March 2018. 1210 [I-D.ietf-tls-tls13] 1211 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1212 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 1213 March 2018. 1215 [I-D.mglt-lurk-lurk] 1216 Migault, D., "LURK Protocol version 1", draft-mglt-lurk- 1217 lurk-00 (work in progress), February 2018. 1219 [I-D.mglt-lurk-tls-use-cases] 1220 Migault, D., Ma, K., Salz, R., Mishra, S., and O. Dios, 1221 "LURK TLS/DTLS Use Cases", draft-mglt-lurk-tls-use- 1222 cases-02 (work in progress), June 2016. 1224 [I-D.rescorla-tls-subcerts] 1225 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 1226 "Delegated Credentials for TLS", draft-rescorla-tls- 1227 subcerts-02 (work in progress), October 2017. 1229 [I-D.sheffer-acme-star-request] 1230 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 1231 Fossati, "Generating Certificate Requests for Short-Term, 1232 Automatically-Renewed (STAR) Certificates", draft-sheffer- 1233 acme-star-request-02 (work in progress), June 2018. 1235 Authors' Addresses 1236 Daniel Migault 1237 Ericsson 1238 8275 Trans Canada Route 1239 Saint Laurent, QC 4S 0B6 1240 Canada 1242 EMail: daniel.migault@ericsson.com 1244 Ioana Boureanu 1245 University of Surrey 1246 Stag Hill Campus 1247 Guildford GU2 7XH 1248 UK 1250 EMail: i.boureanu@surrey.ac.uk