idnits 2.17.1 draft-cdni-fieau-lurk-https-delegation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 24 characters in excess of 72. ** 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 458: '... domain name SHOULD be the same as t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2016) is 2849 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) == Unused Reference: 'I-D.erb-lurk-rsalg' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tls-tls13' is defined on line 698, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 6770 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Downref: Normative reference to an Informational RFC: RFC 7337 ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-18 == Outdated reference: A later version (-20) exists of draft-ietf-cdni-redirection-18 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-13 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Fieau, Ed. 3 Internet-Draft E. Stephan 4 Intended status: Standards Track Orange 5 Expires: January 9, 2017 July 8, 2016 7 Limited Use of Remote Keys for Interconnected CDNs 8 draft-cdni-fieau-lurk-https-delegation-00 10 Abstract 12 Sharing private keys amongst administrative entities raises numerous 13 issues for end-users, intermediaries and content origins. The IETF 14 envisions the standardization of protocols to limit the exchange of 15 private keys (LURK). This document presents CDN Interconnection 16 (CDNI) use cases based on the Limited Use of Remote Keys (LURK) 17 protocol and architecture and identifies a set of requirements. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 9, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. CDNI architecture using LURK . . . . . . . . . . . . . . . . 3 56 4. LURK use cases for CDNI . . . . . . . . . . . . . . . . . . . 6 57 4.1. Use case A: uCDN Key Server . . . . . . . . . . . . . . . 6 58 4.2. Use case B: CSP Key Server . . . . . . . . . . . . . . . 9 59 4.3. Other use cases . . . . . . . . . . . . . . . . . . . . . 11 60 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11 61 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 5.2. CDNI Control Interface requirements . . . . . . . . . . . 11 63 5.3. CDNI Footprint and Capabilities Advertisement interface 64 requirements . . . . . . . . . . . . . . . . . . . . . . 12 65 5.4. CDNI Logging Interface requirements . . . . . . . . . . . 12 66 5.5. Key Server Interface requirements . . . . . . . . . . . . 12 67 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 6.1. HTTPS and TLS . . . . . . . . . . . . . . . . . . . . . . 13 69 6.2. Cyphersuites in CDNI . . . . . . . . . . . . . . . . . . 13 70 6.3. PFS . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 6.4. TLS version . . . . . . . . . . . . . . . . . . . . . . . 13 72 6.5. Scalability . . . . . . . . . . . . . . . . . . . . . . . 13 73 6.6. Certificates and security . . . . . . . . . . . . . . . . 13 74 6.7. Revocation . . . . . . . . . . . . . . . . . . . . . . . 14 75 6.8. Certificate provisioning . . . . . . . . . . . . . . . . 14 76 6.9. CSP side . . . . . . . . . . . . . . . . . . . . . . . . 14 77 6.10. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 14 78 6.11. CDNI Control Interface vs CDNI Metadata Interface . . . . 14 79 7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 7.1. TLS session resuming . . . . . . . . . . . . . . . . . . 14 81 7.2. Stack Evolution . . . . . . . . . . . . . . . . . . . . . 14 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 87 11.2. Informative References . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 CDNI requirements [RFC7337] and use cases [RFC6770] specify the 93 requirements and use cases of HTTP content delivery between CDNs. 94 The intent of this document is to pursue the work by proposing a 95 solution for delegating content delivery over secure protocols like 96 HTTPS or DTLS. Conversely to HTTP delivery, HTTPS [RFC2818] allows 97 content delivery between Content Service Provider (CSP) and End-users 98 with integrity and confidentiality. 100 From the CDNI perspective, all parties - UAs, CSPs origin servers, 101 and CDNs - are involved in the chain of trust and preserving this 102 chain of trust in HTTPS raises concerns. 104 Indeed, regarding TLS certificates, CSPs and CDN providers are 105 reluctant to share private keys mainly because of legal and security 106 issues about private keys. Therefore the CDNI working group must 107 specify a solution that avoids the exchange of private keys between 108 CDNs. 110 This document leverages the work of the LURK initiative 111 [LURK_Mailing_List] and discusses the introduction of a Limited Use 112 of Remote Keys (LURK) solution in the CDNI architecture. It presents 113 2 use cases which complement those described in 114 [I-D.mglt-lurk-tls-use-cases] and identifies a set of requirements 115 for CDNI. Finally it discusses different options and identifies a 116 set of open issues. 118 The proposed use cases are based on DNS redirection. The user agent 119 is redirected to a dCDN to establish a TLS session to get HTTPS 120 content. Additional use cases are expected in future versions of the 121 draft. 123 This version focus on the delivery over HTTPS only. 125 2. Terminology 127 This document uses terminology from CDNI framework documents such as 128 CDNI requirements [RFC7337] and CDNI interface specifications 129 documents - CDNI metadata interface [I-D.ietf-cdni-metadata], CDNI 130 Control interface [I-D.ietf-cdni-control-triggers] and Logging 131 interface [I-D.ietf-cdni-logging]. 133 3. CDNI architecture using LURK 135 This document introduces a Key Server in the CDNI architecture. The 136 general LURK architecture is described in the Session Key interface 137 draft [I-D.cairns-tls-session-key-interface]. 139 +------------+ Handshake +------------------+ LURK +------------+ 140 | TLS Client | <---------> | TLS Server | <-------> | Key Server | 141 +------------+ +------------------+ +------------+ 143 Figure 1: General Key Server Architecture 145 In CDNI, a LURK interface allows private keys to remain under the 146 authority of its owner - typically the CSP or the uCDN - while 147 delivering the content over HTTPS. 149 The LURK interface can be introduced at different locations in the 150 CDNI architecture. The location of the LURK function depends on the 151 use cases. Additionally, this architecture may support variants 152 where the Key server is owned by a third party. 154 +------------+ Handshake +------------------+ LURK +--------------------------------+ 155 | TLS Client | <---------> |dCDN TLS Surrogate| <-------> |(uCDN/CSP/3rd Party) Key Server | 156 +------------+ +------------------+ +--------------------------------+ 158 Figure 2: Key Server in CDNI Architecture 160 This document complements the LURK architecture of 161 [I-D.mglt-lurk-tls-use-cases] with CDNI use cases. In those use 162 cases, content delivery is decoupled from both content acquisition 163 and signaling information needed to route and control the request. 165 Currently CDNI signaling exchanges occur over the Request Routing 166 Redirection interface (information to route the request across CDNs), 167 the Metadata interface (per content or group of content information 168 about the acquisition and the delivery), the Logging interface 169 (exchange of monitoring information about the delivery) and the 170 Control interface (information for controlling the lifecycle of the 171 aforementioned interfaces). 173 The LURK interface for CDNI adds two types of exchange: one for 174 acquiring the certificate associated with the origin domain and the 175 other for establishing delivery confidentiality and integrity. 177 This document presents two use cases of HTTPS delivery which rely on 178 a LURK function to avoid exchanging private keys between CDNs: 180 A. uCDN Key server: the CSP has provided his certificate and private 181 keys to the uCDN. the uCDN provides the LURK key server and 182 interface. 184 B. CSP Key server: the CSP provides the LURK Key Server and 185 interface. 187 The table below presents the use cases developed in the Section 3. 189 +-------------+--------------+----------------+-------------------+ 190 |Use Case name|UA Redirection|uCDN redirection|CSP Cert delegation| 191 +-------------+--------------+----------------+-------------------+ 192 |UC A: uCDN KS|DNS CNAME |recursive |uCDN | 193 +-------------+--------------+----------------+-------------------+ 194 |UC B: CSP KS |DNS CNAME |recursive |No | 195 +-------------+--------------+----------------+-------------------+ 197 Figure 3: Use cases description table 199 The use cases' call flows are respectful of the CDNI redirection 200 [I-D.ietf-cdni-redirection] for the description of redirection 201 methods in CDNI. 203 They share the same steps. 205 The figure below illustrates the framework use cases where the 206 surrogate doesn't handle the CSP private keys and where the surrogate 207 remotely accesses materials to sign and encrypt information exchanged 208 over the TLS connection. 210 +----+ +----------+ +----------+ +------+ 211 | UA | |surrogate*| |Key Server| |Origin| 212 +----+ +----------+ +----------+ +------+ 213 |... | | | 214 |1. TLS clientHello | | | 215 |------------------->| | | 216 | | | | 217 | | | | 218 |2. TLS serverHello |+-----------------+| | 219 |<-------------------|| || | 220 | || || | 221 |3. Certificate || || | 222 |<-------------------|| LURK Exchanges || | 223 | ||<--------------->|| | 224 | || || | 225 | || || | 226 | || || | 227 | |+-----------------+| | 228 |4. ServerKeyExchange| | | 229 |<-------------------| | | 230 |... Continued | | | 232 Figure 4: LURK exchanges in CDNI architecture 234 4. LURK use cases for CDNI 236 Two use cases are considered in this document to implement LURK in 237 CDNI: 239 Use Case A. uCDN Key Server 241 Use Case B. CSP Key Server 243 4.1. Use case A: uCDN Key Server 245 In this use case, the dCDN has a LURK interface to a Key Server 246 hosted at the uCDN side. It may be typically a case of CDNI regional 247 delivery delegation. 249 This following example is based on ECDHE cypher suite. The UA is 250 first redirected from the uCDN to a dCDN using a recursive DNS 251 redirection. Then the UA initiates a TLS connection with the dCDN to 252 get his content. Since the dCDN does not store the private keys for 253 the requested certificate, it queries the uCDN Key Server (KS) to get 254 the credential to establish the TLS session with the User Agent. 255 Finally the dCDN can deliver the content in HTTPS to the UA using the 256 CSP certificate. 258 The UA sends an HTTPS request to the CSP to get a content. 260 a. to d. As seen on figure 5, once the DNS resolution is over, 261 i.e., UA was able to resolve dCDN surrogate IP@ steps [a.] to 262 [d.], the user agent connects to the dCDN surrogate. Note that 263 DNS cache is not shown on the figure. 265 1. The UA sends a ClientHello, as defined in the TLS protocol 266 [RFC5246]. The SNI field of the ClientHello includes the CSP 267 domain name. 269 2. The surrogate receives the ClientHello from the UA, and sends 270 a ServerHello to the UA. 272 3. The surrogate parses the SNI field, and determines the Key 273 Server interface of the CSP domain name. The surrogate uses this 274 piece of information to determine the certificate of the delivery. 275 The surrogate sends the public certificate to the UA. The UA 276 validates the certificate. 278 4. The surrogate determines the ECDHE parameters, and requests 279 the Key Server to sign these parameters with the CSP private key. 280 The request includes the domain name received by the surrogate in 281 the SNI field of the ClientHello. 283 5. The Key Server returns the necessary credentials to the dCDN 284 surrogate over a secure tunnel. 286 6. and 7. the UA and the surrogate exchange public DH parameters 287 and compute session keys. 289 8. The UA and the surrogate establish a secure connection. The 290 UA issues its request for content over HTTPS. 292 The surrogate then processes the original request. 294 Below is an example of the handshake establishment: 296 +----+ +----+ +-------+ +----+ 297 | UA | |dCDN| |uCDN KS| |uCDN| 298 +----+ +----+ +-------+ +----+ 299 |a. DNS A? FQDN CSP | | | 300 |---------------------------------------------------------------->| 301 | | | | 302 |b. DNS CNAME dCDN | | | 303 |<----------------------------------------------------------------| 304 | | | | 305 |c. DNS A? dCDN | | | 306 |------------------->| | | 307 | | | | 308 |d. DNS A IP Surrogate | | 309 |<-------------------| | | 310 | | | | 311 |1. ClientHello (Client Random) | | 312 |------------------->| | | 313 | | | | 314 |2. ServerHello (Server Random) | | 315 |<-------------------| | | 316 | | | | 317 |3. Certificate (Server certificate) | | 318 |<-------------------| | | 319 | | | | 320 | |4. LURK query for Signature (ECDHEParams) | 321 | |------------------>| | 322 | | | | 323 | |5. LURK response: signature (ECDHEParams) | 324 | |<------------------| | 325 | | | | 326 |6. ServerKeyExchange (ECDHParams, Signature) | 327 |<-------------------| | | 328 | | | | 329 |7. ClientKeyExchange (clientDHpublic) | | 330 |------------------->| | | 331 |Finished | | | 332 |<------------------>| | | 333 | | | | 334 |8. HTTPS request | | | 335 |------------------->| | | 337 Figure 5: Key Server hosted by uCDN 339 4.2. Use case B: CSP Key Server 341 This section describes a use case in CDNI where the CSP provides the 342 Key Server (KS). 344 In this example, the CSP delegates the HTTPS content delivery to an 345 uCDN that in turn delegates the HTTPS delivery to a dCDN. For 346 obvious legal or security reasons, the CSP does not want his private 347 keys to be stored on all CDNs involved in the interconnection. In 348 that case, the dCDN relies on credentials received from a CSP Key 349 Server (KS) to deliver HTTPS content. 351 The dCDN cannot here request the KS directly. Instead, the dCDN LURK 352 request will be relayed by the uCDN to the Key Server. Prior to 353 that, the uCDN has to check whether the received LURK request is 354 valid, e.g., complies with Content Distribution policies 355 [I-D.ietf-cdni-metadata]. 357 In the following example, the CSP stores his certificates and private 358 keys on a Key Server that is able to compute and provide credentials 359 for TLS establishment. 361 1. The UA sends a ClientHello to the dCDN's surrogate, as defined 362 in the TLS protocol [RFC5246]. The SNI field of the ClientHello 363 includes the CSP domain name. 365 2. The dCDN's surrogate receives the ClientHello from the UA, and 366 sends a ServerHello to the UA.. 368 3. The surrogate parses the SNI field, and determines the Key 369 Server interface of the CSP domain name and determine the 370 certificate of the delivery. The surrogate sends the public 371 certificate to the UA. The UA checks the certificate signature 372 with the public key. 374 4. The dCDN's surrogate requests the uCDN to sign parameters with 375 the private key. 377 5. The uCDN parses the SNI field, and determines the Key Server 378 interface of the CSP domain name. The uCDN relaies the LURK 379 request received from the dCDN's surrogate, to the Key Server to 380 sign parameters with the private key. 382 6. The Key Server returns the necessary credentials to the uCDN 383 surrogate. 385 7. The uCDN returns the necessary credentials to the dCDN's 386 surrogate. 388 8. and 9. the UA and the surrogate exchange public DH parameters 389 and compute session keys. 391 10. The UA and the surrogate establish a secure connection. The 392 UA issues its request for content over HTTPS. 394 The surrogate then processes the original request. 396 +----+ +----+ +----+ +------+ 397 | UA | |dCDN| |uCDN| |CSP KS| 398 +----+ +----+ +----+ +------+ 399 | (DNS redirection) | | | 400 | | | | 401 |d. DNS A IP Surrogate | | 402 |<-------------------| | | 403 | | | | 404 |1. ClientHello (Client Random) | | 405 |------------------->| | | 406 | | | | 407 |2. ServerHello (Server Random) | | 408 |<-------------------| | | 409 | | | | 410 |3. Certificate (Server certificate) | | 411 |<-------------------| | | 412 | | | | 413 | |4. LURK query for Signature (ECDHEParams) | 414 | |------------------>| | 415 | | |5. LURK query for sign. | 416 | | |----------------------->| 417 | | | | 418 | | |6. LURK response | 419 | | |<-----------------------| 420 | | | | 421 | |7. LURK response: signature (ECDHEParams) | 422 | |<------------------| | 423 | | | | 424 |8. ServerKeyExchange (ECDHParams, Signature) | 425 |<-------------------| | | 426 | | | | 427 |9. ClientKeyExchange (clientDHpublic) | | 428 |------------------->| | | 429 |Finished | | | 430 |<------------------>| | | 431 | | | | 432 |10. HTTPS request | | | 433 |------------------->| | | 434 Figure 6: Cascaded delegation with LURK 436 4.3. Other use cases 438 Other use cases will be described in a further version of this draft. 440 5. Requirements 442 This section is a first attempt to identify the requirements 443 introduced by the delivery of HTTPS content. Some of the 444 requirements are new, whereas others may update existing CDNI 445 requirements [RFC7337]. 447 5.1. General 449 LURK-GEN-1: The specification should not require any change in User 450 Agent. This is already stated in [RFC7337]/GEN-2 452 Discussion: Despite this is obvious, it is important to notice that 453 recent limitation in TLS (version, cyphers...) or HTTP (cyphers) 454 documents may constrain User Agent. 456 LURK-GEN-2: The user agent should be able to see that the requested 457 content is delivered by the CDN using the CSP domain. Delivery 458 domain name SHOULD be the same as the CSP portal domain name (or a 459 sub-domain request name) 461 LURK-GEN-3: The Certificate delivered by the dCDN and CSP must match 462 the domain of the URL [RFC2818]. As an example, it means that no 463 certificate error occurs on the UA when the dCDN has redirected the 464 UA a dCDN. 466 LURK-GEN-4: The dCDN's surrogates which implements LURK interface 467 should support the delivery of content of the protocol HTTPS. 469 LURK-GEN-5: The dCDNs must be able to present the CSP certificate and 470 credentials to the user agent when establishing a TLS session 472 5.2. CDNI Control Interface requirements 474 LURK-CI-1: The CDNI Control Interface may allow the bootstrapping of 475 a Key Server interface. For example this may include: 477 - discovery the Key Server interface endpoint. 479 - credentials for Key Server and CDN mutual authentication. 481 - TLS version, Certificate types, TLS crypto suites. 483 Proposal: add this requirement to the section CDNI Control Interface 484 of [RFC7337]. 486 5.3. CDNI Footprint and Capabilities Advertisement interface 487 requirements 489 LURK-FC-1: The CDNI Footprint and Capabilities Advertisement 490 interface should allow the downstream CDN to communicate to the 491 upstream CDN about its capabilities regarding the support of client 492 side of the Key Server interface. 494 5.4. CDNI Logging Interface requirements 496 This section identifies additional requirements related to the CDNI 497 Logging interface (LI). 499 TLS-LI-1: the CDNI Logging interface should allow a dCDN to report to 500 the uCDN logging for deliveries which fail during the establishment 501 of the secure connection, e.g., ability to report certificate 502 validation error. 504 TLS-LI-2: The CDNI Logging interface should allow dCDN to report to 505 uCDN logging incomplete deliveries due to encryption errors. 506 Discussion: this requirement is mostly a subcase of LI-2 about 507 incomplete deliveries. 509 LURK-LI-3: the CDNI Logging interface should allow a dCDN to report 510 to the uCDN secure connections failures when using LURK interface. 512 As an example, the UA can't establish a secure connection to a dCDN 513 because either, the credentials provided by a Key Server are invalid, 514 or because the Key Server has refused to provide them to the dCDN. 516 5.5. Key Server Interface requirements 518 LURK-KS-1: A Key Server interface must not allow the exchange private 519 keys. This is the centrality of the LURK interface. 521 LURK-KS-2: The Key Server and the requesting CDN must authenticate 522 each other, according to the information provided by the CDNI Control 523 interface. 525 LURK-KS-3: The dCDN Key Server interface must be able to send a LURK 526 request to a Key Server. 528 As an example (UC A, step 4), the dCDN surrogate determines ECDHE 529 parameters (...), and requests the Key Server to sign these 530 parameters with the CSP private key. The request includes the domain 531 name received by the surrogate in the SNI field of the ClientHello. 533 6. Discussions 535 6.1. HTTPS and TLS 537 HTTPS contents are delivered with the dCDN credentials. The 538 introduction of a Key Server in the CDNI architecture allows the 539 HTTPS content to be delivered with the CSP origin server certificate. 540 It conforms to the end-to-end HTTPS framework [RFC7230]. 542 6.2. Cyphersuites in CDNI 544 CDNI WG and LURK WG should use a common set of cyphersuites, or CDNI 545 WG should specify or points to the set of suites to support. 547 TLS and HTTP2 recommend different set of cypher suites. CDNI WG 548 should clarify which one should be supported in the case of a HTTPS 549 delivery based on LURK credentials: HTTP2 Cipher Suite, refer to 550 appendix A of [RFC7540] and "backwards-compatibility-security- 551 restrictions" in [I-D.draft-ietf-tls-tls13"]. 553 6.3. PFS 555 Should the delivery be PFS proof? 557 6.4. TLS version 559 Which version of TLS should be supported by LURK: TLS/LTS, TLS1.2, 560 TLS1.3? 562 6.5. Scalability 564 For each TLS session initialization on the dCDNs, the dCDNs need to 565 request the KS to get the necessary credentials. To be scalable, the 566 KS may need to be replicated. 568 6.6. Certificates and security 570 At least one private key per CSP is stored on the KS. Therefore the 571 use of a KS avoids the complexity of duplicating private keys on 572 uncontrolled servers. This also allows the uCDN to maintain a single 573 domain name for the CDN interconnection. 575 6.7. Revocation 577 In the case of an HTTPS delegation revocation, a dCDN has no longer 578 the delegation right to deliver a content for a given CSP. The uCDN 579 would then deny access to CSP certificates and credentials derived 580 from private keys, and therefore the dCDN would not be able to 581 establish the TLS session without triggering a warning on UA Side. 583 6.8. Certificate provisioning 585 The dCDN may have to retrieve at least once the CSP public 586 certificate related to the targeted domain name. The certificates 587 may be cached on the dCDN for a given duration. . 589 Is certificate provisioning in the scope of CDNI as it seems 590 implementation dependant? Which interface provides the certificates 591 to the uCDN (Control, Metadata, LURK, ..)? 593 6.9. CSP side 595 With regard to the use case B, the CSP may provide a Key server. As 596 a consequence the requirement [RFC7337]/GEN-3 should be updated 597 accordingly. 599 6.10. Acquisition 601 Usage of the LURK interface when acquiring content: when the dCDN 602 acquires content directly from the origin server, would it have to 603 request first the KS to get the uCDN credentials ? 605 6.11. CDNI Control Interface vs CDNI Metadata Interface 607 What should be carried by the CI or the MI ? 609 7. Open issues 611 7.1. TLS session resuming 613 Not yet addressed in this document, contributors are welcome. 615 7.2. Stack Evolution 617 Contents might be delivered over other protocols than TCP and than 618 HTTP/1.1 in a close future. The CDNI WG must discuss the support of 619 HTTPS delivery over TLS/LTS, TLSv3, DTLS, QUIC and HTTP2. 621 8. IANA Considerations 623 This document has no IANA considerations. 625 9. Security Considerations 627 The entire document is about security. 629 10. Acknowledgments 631 Many thanks to Benoit Gaussen who contributed to this draft. 633 11. References 635 11.1. Normative References 637 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 638 DOI 10.17487/RFC2818, May 2000, 639 . 641 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 642 (TLS) Protocol Version 1.2", RFC 5246, 643 DOI 10.17487/RFC5246, August 2008, 644 . 646 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 647 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 648 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 649 November 2012, . 651 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 652 Protocol (HTTP/1.1): Message Syntax and Routing", 653 RFC 7230, DOI 10.17487/RFC7230, June 2014, 654 . 656 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 657 Network Interconnection (CDNI) Requirements", RFC 7337, 658 DOI 10.17487/RFC7337, August 2014, 659 . 661 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 662 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 663 DOI 10.17487/RFC7540, May 2015, 664 . 666 11.2. Informative References 668 [I-D.cairns-tls-session-key-interface] 669 Cairns, K., Mattsson, J., Skog, R., and D. Migault, 670 "Session Key Interface (SKI) for TLS and DTLS", draft- 671 cairns-tls-session-key-interface-01 (work in progress), 672 October 2015. 674 [I-D.erb-lurk-rsalg] 675 Erb, S. and R. Salz, "A PFS-preserving protocol for LURK", 676 draft-erb-lurk-rsalg-01 (work in progress), May 2016. 678 [I-D.ietf-cdni-control-triggers] 679 Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / 680 Triggers", draft-ietf-cdni-control-triggers-15 (work in 681 progress), May 2016. 683 [I-D.ietf-cdni-logging] 684 Faucheur, F., Bertrand, G., Oprescu, I., and R. 685 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 686 logging-27 (work in progress), June 2016. 688 [I-D.ietf-cdni-metadata] 689 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 690 "CDN Interconnection Metadata", draft-ietf-cdni- 691 metadata-18 (work in progress), June 2016. 693 [I-D.ietf-cdni-redirection] 694 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 695 Redirection interface for CDN Interconnection", draft- 696 ietf-cdni-redirection-18 (work in progress), April 2016. 698 [I-D.ietf-tls-tls13] 699 Rescorla, E., "The Transport Layer Security (TLS) Protocol 700 Version 1.3", draft-ietf-tls-tls13-13 (work in progress), 701 May 2016. 703 [I-D.mglt-lurk-tls-use-cases] 704 Migault, D., Ma, K., Salz, R., Mishra, S., and O. Dios, 705 "LURK TLS/DTLS Use Cases", draft-mglt-lurk-tls-use- 706 cases-02 (work in progress), June 2016. 708 [LURK_Mailing_List] 709 "LURK Mailing List", . 712 Authors' Addresses 714 Frederic Fieau (editor) 715 Orange 716 40-48, avenue de la Republique 717 Chatillon 92320 718 France 720 Email: frederic.fieau@orange.com 722 Emile Stephan 723 Orange 724 2, avenue Pierre Marzin 725 Lannion 22300 726 France 728 Email: emile.stephan@orange.com