idnits 2.17.1 draft-fieau-cdni-https-delegation-02.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 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 313: '...advises "clients MUST NOT accept deleg...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2487 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: 'RFC5280' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'RFC6844' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-acme-caa' is defined on line 594, 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) ** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659) == Outdated reference: A later version (-10) exists of draft-ietf-acme-caa-02 == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-00 == Outdated reference: A later version (-02) exists of draft-rescorla-tls-subcerts-01 Summary: 4 errors (**), 0 flaws (~~), 7 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 4, 2018 S. Mishra 6 Verizon 7 July 3, 2017 9 HTTPS delegation in CDNI 10 draft-fieau-cdni-https-delegation-02 12 Abstract 14 This document examines probable solutions for delegating encrypted 15 content delivery within the context of CDN interconnection. The 16 HTTPS delegation also expects delivering content without compromising 17 security, integrity and user privacy. 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 4, 2018. 36 Copyright Notice 38 Copyright (c) 2017 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. LURK for CDNI . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. uCDN Key Server (CDNI framework) . . . . . . . . . . . . 4 57 3.2. CSP Key server . . . . . . . . . . . . . . . . . . . . . 4 58 4. Out-of-Band for CDNI . . . . . . . . . . . . . . . . . . . . 5 59 4.1. OOB overview . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. OOB applied to CDNI . . . . . . . . . . . . . . . . . . . 6 61 5. Sub-certificates and Short-lived Certificates for CDNI . . . 7 62 5.1. Short-lived certs use case for CDNI - ACME . . . . . . . 7 63 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. LURK . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.2. OOB . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6.3. Subcerts and SLC . . . . . . . . . . . . . . . . . . . . 10 67 6.4. HTTPS delegation requirements . . . . . . . . . . . . . . 11 68 6.5. Implementation status . . . . . . . . . . . . . . . . . . 11 69 6.6. E2E HTTPS delegation for CDNs . . . . . . . . . . . . . . 11 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 9.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 Currently, sixty percent of the HTTP traffic on the internet is 80 encrypted, that is, it is transported over TLS [RFC5246]. At the 81 same time, HTTP traffic served by CDNs is on the rise as well. The 82 traffic on CDNs is estimated to raise to seventy-five percent in year 83 2020 [ciscotraffic]. 85 This document discusses viability of and solution for addressing 86 delegation of HTTP over TLS [RFC2818] traffic within the context of 87 CDN interconnection. HTTPS delegation allows delivering party, e.g. 88 a CDN, to deliver content for and on-behalf of an origin server. 90 This draft considers three approaches for delegating HTTPS traffic in 91 a CDNI context. These include Limited Use of Remote Keys (LURK), 92 Out-of-Band, Short-Lived Certificates and Sub-Certificates (or 93 delegated credentials). We examine these approaches focusing on the 94 following three issues: 96 o Modification (or no) changes in the user agent 98 o Trust delegation (transitivity, that is, Is a CDN allowed to 99 delegate the trust it received directly from the Origin?) 101 o Maintain the user experience (privacy, integrity and performance) 103 To recap CDNi goals, the CDNi WG focuses on the relationship between 104 the upstream CDN and the downstream CDN. Therefore, this document 105 examines applicability of HTTPS delegation between two CDNs in 106 response to a UA request while maintaining end-to-end integrity of UA 107 request. 109 2. Terminology 111 o UA: User Agent 113 o CDNI: Content Delivery Network 115 o SLC: Short-Lived certificates 117 o LURK: Limited Use of Remote Keys 119 o dCDN: downstream Content Delivery Network 121 o uCDN: upstream Content Delivery Network 123 o CSP: Content Service Provider 125 o OOB: Out-of-Band 127 o PKS: Private Key Server 129 3. LURK for CDNI 131 [I-D.cdni-fieau-lurk-https-delegation] shows 2 use cases related to 132 CDN interconnection based on LURK [I-D.mglt-lurk-tls-use-cases]: 134 o uCDN Key Server: uCDN is authoritative on several origin domains. 135 Its key Server hosts certificates and private keys of these 136 origins. An interface between uCDN and dCDN allows dCDN to query 137 credentials per session for these origins. Note that a dCDN is 138 typically connected to several uCDNs. 140 o CSP Key Server: a Content Service Provider is authoritative source 141 for origin domains. CSPs key Server hosts certificates and 142 private keys for its domains. An interface between this key 143 Server and the dCDN allows the dCDN to query credentials for a 144 given session for these origins. 146 3.1. uCDN Key Server (CDNI framework) 148 dCDNs have an interface to a Key Server hosted at the uCDN side. It 149 may be typically a case of CDNI regional delivery delegation. 151 When the UA has been redirected from the uCDN to a dCDN,it initiates 152 a TLS connection with a dCDN cache to get its content. Since dCDN 153 cache does not store the private keys for the requested certificate, 154 it queries the uCDN Key Server (KS) to get credentials to establish 155 the TLS session. Once the UA establishes a TLS connections with the 156 dCDN, the dCDN can finally begin to deliver HTTP over TLS content to 157 the UA. 159 This framework makes two assumptions: 161 o The UA includes the Origin domain name in the SNI field of the TLS 162 ClientHello to enable a dCDN to select the Key Server of uCDN to 163 generate credentials for the session. 165 o The uCDN Key Server is provisioned with the certificate and the 166 private key for this Origin domain name. 168 3.2. CSP Key server 170 In this framework the CSP provides a Key Server for the origin 171 domains it is authoritative for to ensure an end-to-end HTTPS 172 delegation, from the origin to the dCDN which eventually delivers the 173 HTTPS content to the UA. The CSP provides the LURK Key Server and 174 interface. 176 The CSP delegates the HTTPS content delivery to an uCDN that in turn 177 delegates the HTTPS delivery to a dCDN. The CSP provides the uCDN 178 with a Key Server interface to delegate the content delivery. In 179 that case, the dCDN relies on credentials received from a CSP Key 180 Server (KS) to deliver HTTPS content. 182 This framework supports 2 options: 184 o direct: The dCDN requests directly the CSP key server 186 o cascaded: the dCDN session key requests are relayed by the uCDN to 187 the Key Server 189 4. Out-of-Band for CDNI 191 This section presents the usage of HTTP Out-of-Band mechanism 192 [I-D.reschke-http-oob-encoding] to deliver HTTPS content in CDNI. 194 4.1. OOB overview 196 Out-of-Band HTTPS content delivery (OOB) relies on the use of the 197 "out-of-band" value in "Accept-encoding" HTTP header of the request. 198 It indicates that the UA supports downloading the resource from 199 alternative locations than the Origin. To that purpose, when the 200 out-of-band content encoding is set, the Origin server may respond 201 with a list of caches to fetch the requested resource. 203 Example: 205 {sr: [{r:"https://ori/path/content1", r:"https://cdn1/path/content1"}]} 207 +----------+ +----------------+ +-------------+ 208 | UA |--3) GET --->| cache |--4) GET---> |Origin Server| 209 +----+-----+ content +----------------+ content +----+--------+ 210 | ^ | ^ 211 | |---------- 2) 2OO OK, OOB + resource map-----------+ | 212 |--------------------- 1) HTTP GET content -------------------+ 214 Figure 1: OOB general principle 216 Out-of-Band framework involves the following functional entities: 218 Origin server: 220 o OOB specifies the first step of the HTTPS delivery delegation: the 221 soft redirection toward alternative locations that Origin trusts 222 in a resource map. 224 o The Origin server receives new HTTP header value "accept-encoding" 225 and responses with a "content-encoding" 227 UA: 229 o must store resource map received from the Origin server 231 o must support new HTTP header "accept-encoding" values to comply 232 with OOB 234 Cache server: 236 o has standard cache functions, and supports TLS for delivery and 237 content provisioning from origin. 239 o When the cache receives a request from the UA, it uses the "http 240 referer" of the request to know the origin url from where to pull 241 and store the requested content. 243 4.2. OOB applied to CDNI 245 In CDNI, uCDN may use OOB to direct a UA to dCDN by indicating a 246 resource map where it can fetch content. In CDNI, an end-to-end 247 delegation allows an origin delegate HTTPS delivery to uCDN which in 248 turns delegates it to dCDN. 250 For instance, end-to-end delegation may involve cascaded resource 251 maps. The Origin delegates HTTPS delivery to the uCDN using OOB, and 252 uCDN delegates HTTPS delivery to dCDN through OOB. In that case, the 253 UA requests Origin that sends back a resource map pointing at the 254 uCDN. Then UA requests the uCDN which sends back a resource map 255 (OOB) pointing at dCDN hosted resources. 257 User Agent dCDN uCDN Origin 258 | | | | 259 | GET http://origin/hash1/content | | 260 +----------------------------------------------------->| 261 | 200 OK + OOB | | 262 +<-----------------------------------------------------| 263 | GET http://ucdn/hash2/content | | 264 +------------------------------------>| | 265 | 200 OK + OOB | | 266 |<------------------------------------+ | 267 | | | | 268 |GET http://dcdn/hash2/content | | 269 +----------------->| | | 270 | | GET http://ucdn/hash2/content | 271 | |----------------->| | 272 | | 200 OK (encrypted content) | 273 | |<-----------------| | 274 | 200 OK (encrypted content) | | 275 |<-----------------+ | | 276 | | | | 277 figure 2: OOB with successive resource maps in CDNI 279 5. Sub-certificates and Short-lived Certificates for CDNI 281 The need to scale is a central requirement to generalize HTTPS 282 content delivery across CDNs. Both [I-D.rescorla-tls-subcerts] and 283 [I-D.ietf-acme-star] share the same paradigm. They aim to decouple 284 credentials provisioning from content delivery. 286 The [I-D.ietf-acme-star] cert architecture adds interactions between 287 the CDN and the Origin and between the Origin and the CA which signs 288 the limited authority delegation; 290 [I-D.ietf-acme-star] certificate implementation do not require 291 modifications in the UA, but requires specific certificate request 292 from CSP to CA and retrieval of certificate by CDN from the CA. The 293 [I-D.rescorla-tls-subcerts] proposes an architecture where the TLS 294 server by itself can create a sub-certificate (also referred to as 295 "delegated credentials") based on the original certificate issued to 296 it by the CA. This sub-certificate's scope is only to the 297 credentials issued by the CA corresponding to the original 298 certificate the CA authorized the TLS server. 300 A possible applicability of this may be where a uCDN may issue 301 "delegated_credentials" to a dCDN for any HTTPS content it delegates 302 to dCDN for delivery. 304 This new "delegated certificate" will have a validity interval (7 305 days) along with the public key issued to the Content Service 306 Provider (CSP) or to its surrogate (CDN) by the CA. 308 The Subcerts require changes to the user agent. The 309 [I-D.rescorla-tls-subcerts] draft proposes User Agent to send an 310 empty "delegated_credential" extension in its ClientHello. The draft 311 also defines a new "DelegationUsage" extension to X.509. Only 312 presence of this this extension shall permit usage of delegated 313 credentials. The draft advises "clients MUST NOT accept delegated 314 credentials associated with certificates without this extension." 315 The applicability of subcerts in case of CDN would be when a uCDN 316 with a certificate can issue a "delegated credentials" to a dCDN. 318 5.1. Short-lived certs use case for CDNI - ACME 320 [I-D.ietf-acme-star] specifies mechanisms to allow a third party such 321 as a CDN to terminate a TLS session on behalf of a content owner 322 (described as domain name owner) The proposal calls for an extension 323 to the ACME protocol to enable the issuance of short term and 324 automatically renewed certificates and a protocol that allows a 325 Domain Name Owner (DNO) to delegate to a third party control over a 326 certificate that bears its own name. 328 Compared to per session key exchange, it decouples the credentials 329 provisioning from the content delivery to limit the burden on the CSP 330 side. It limits signaling to periodic short term certificate 331 requests (CSR) sent from the uCDN to the content owner: 333 o As a Bootstrap process, the CDN generates a key-pair and wraps it 334 into a Certificate Signing Request (CSR) according to the agreed 335 CSR template and sends a request over the pre-established LURK 336 channel requests to the DNO. The DNO in turn forwards request 337 over an ACME protocol to an ACME CA to create the corresponding 338 short-term and auto-renewed (STAR) certificate; 340 o The ACME CA posts the certifcate and notifies the DNO and DNO in 341 turn notifies the CDN which downloads the certificate. 343 o The connection between CDN and the Origin is mutually 344 authenticated. The additional requests are processed as such as: 346 Auto-renewal: the ACME CA periodically re-issues the short-term 347 certificate and posts it to a public URL. The CDN would periodically 348 retrieve the certificate 350 Termination: the DNO (indirectly) stops name delegation by explicitly 351 requesting the ACME CA to discontinue the automatic renewal of the 352 certificate. 354 CDN and DNO have agreed on a "CSR template" to use, including subject 355 name, Validity, Requested Algorithm, Key length and Key usage. 357 The ACME issued CA has a short validity (24 hours to 72 hours). 359 6. Discussions 361 6.1. LURK 363 A LURK interface may provide advantages to HTTPS delegation in CDNI 364 such as: 366 o The origin of the information can be preserved, provided that DNS 367 is used to redirect a UA from the uCDN to a dCDN 369 o It mitigates the risks of CSP private keys leak by centralizing 370 them. 372 o It doesn't impact the UA nor TLS stack 374 o Revocation of delegation may be straightforward by denying any 375 access to private key server 377 However, preserving UX performances cannot be guaranteed as 378 additional RTT are needed to fetch the needed session credentials 379 from the Key Server. 381 6.2. OOB 383 OOB may provide advantages to HTTPS delegation in CDNI such as: 385 o CDNs can be agnostic of the cached contents; contents can actually 386 remain encrypted on the cache when HTTP encryption encoding 387 [I-D.ietf-httpbis-encryption-encoding] is used, which can be 388 valuable for the Content owner/provider. 390 o Origin URL stays unchanged in the address bar. So that Origin of 391 information is preserved. 393 However, the use of OOB to ensure HTTPS delegation in CDNI should be 394 clarified in many cases: 396 o Origin issue: how to preserve Origin in case of OOB chaining in 397 CDNI? 399 o How to improve OOB performance in E2E delegation, i.e., from the 400 Origin to dCDN, within a single OOB resource map received by the 401 UA? 403 o OOB for ensuring E2E delegation would raise delegation issues in 404 certain cases: 406 1. For instance, an E2E delegation using OOB with DNS redirect would 407 raise a delegation issue where the requested domain doesn't match the 408 URI which may trigger a warning on the UA. As such, delegation is 409 not solved (HARD problem). 411 The Origin delegates the delivery to uCDN with OOB, next the uCDN 412 delegates HTTPS delivery to a dCDN using DNS.In that case, the UA 413 requests origin that sends back a resource map pointing at uCDN, UA 414 DNS then queries uCDN.com which is resolved to a dCDN server IP, the 415 UA requests contents on dCDN server 417 2. In another example, an E2E delegation using 302 redirect first 418 and OOB next, would raise a delegation issue where the origin of 419 information is the uCDN, not the Origin. 421 The Origin delegates HTTPS delivery to uCDN through a 302 redirect, 422 next uCDN delegates HTTPS delivery to dCDN using OOB. In that case, 423 the UA requests Origin who redirects it to the uCDN using 302 HTTP, 424 then UA requests the uCDN which answers OOB content pointing at dCDN, 425 then UA requests content on dCDN. 427 Finally, some clarifications about OOB draft are needed: 429 o How to avoid circular redirection 431 o Does the UA insert the out-of-band header in any request? 433 o Does the UA insert the out-of-band header when it requests a 434 resource it selected in a resource map it received in an "out-of- 435 band" response received from the origin? 437 6.3. Subcerts and SLC 439 The motivation of [I-D.rescorla-tls-subcerts] draft is to remove 440 dependency between the Origin Server or its surrogates and the CA 441 specifically for enabling the ability to issue credentials (sub- 442 certificates) under the authority of its own certificate and 443 importantly, manage lifetime of the certificates and also have the 444 ability to support any new cryptographic algorithms. The intent for 445 the authors is to give Origin Servers (or their surrogates) 446 operational independence when needing to either limit the life of a 447 certificate or when needing to issue a sub-certificate with limited 448 life. This process may be expeditious over needing to work with the 449 CA for either of the aforementioned changes while still preserving 450 the security and integrity of the content and communications between 451 the origin server or it's and surrogate and the client. 453 The [I-D.rescorla-tls-subcerts] draft explores several options to 454 allow origin server or its surrogate with capabilities to issue a 455 sub-certificate or delegated credentials with limited authority. The 456 draft also provides for ways where a client controls issuance of sub- 457 certificates. This control can be exerted by the clients by use of 458 an optional "delegated_credential" extension field in the 459 clientHello. The draft also calls out rules for its use, such as, a 460 server cannot unilaterally send this extension but that it can only 461 send credentials when presented by the clientHello message. The 462 draft also defines "DelegationUsage" extension to X.509 that 463 determines use of delegated credentials. 465 However, as noted in sub-sections, 5.2, the applicability of this 466 draft may be limited in cascaded delegation that is from an up stream 467 CDN to the downstream CDN. Further clarity may be required from the 468 [I-D.rescorla-tls-subcerts] draft authors on ability to cascade sub- 469 certificates. 471 The [I-D.ietf-acme-star] and the [I-D.rescorla-tls-subcerts] propose 472 approaches where a TLS server, i.e., a uCDN issue certificates or a 473 sub-certificate with limited authority and time without having to 474 share a private key. The approaches avoid any additional 475 infrastructure cost and potential for scaling up the solution. One 476 of the key drawbacks with either approach is additional changes 477 required such as uCDN with content owner and CA for 478 [I-D.ietf-acme-star]. Additionally, a short-lived certificate 479 creation system must be fully automated, as manual renewal of 480 certificates every few days is not practical. An automated system 481 requires require business relations and agreement between the SP and 482 CDN, and an initial setup. In case of [I-D.rescorla-tls-subcerts], 483 the proposal requires changes to TLS handshake where the client 484 provides an extension in its ClientHello that indicates support for 485 this mechanism. 487 6.4. HTTPS delegation requirements 489 Generic HTTPS delegations requirements that should be discussed: 491 o No changes in the client: delegation doesn't impact code on UA 492 side. 494 o No (or few) impacts on the CSP side: e.g. the load of signaling 495 introduced by the solution should be limited on CSP side 497 o Preserves the Origin of information: e.g., Origin URL in address 498 bar is preserved. 500 6.5. Implementation status 502 At the time being, LURK, OOB and subcerts are in early stage. 503 Currently SLC and subcerts are not available and need to be 504 clarified. However some prototypes already exists for OOB 505 [EricssonOOB]. 507 6.6. E2E HTTPS delegation for CDNs 509 In order to ensure an end-to-end delegation from the Origin to dCDN, 510 a CDNI HTTPS delegation solution may combine several options 511 described in this document. 513 o LURK can allow the preservation of Origin of information, and 514 mitigates the risk of private CSP keys leakage. Regarding 515 performance, requesting a key server can lead to an increase in 516 Time To Service (Time to First Page) for UA but does not impact 517 downloading performances. 519 o OOB allows preserving origin URL while avoiding spreading of 520 private keys on CDN caches, but impacts UA. As far performance is 521 concerned, downloading successive resource maps and direct to the 522 requested resource can increase Time To Service (Time to First 523 Page), but still it does not impact content delivery performance. 525 o SubCerts: The motivation for sub-certificate 526 (delegated_credential) is to give an option to certificate holder 527 to create a sub-certificate and sign the credentials. The sub- 528 certificate shall have a validity interval with limited scope. On 529 top, the server cannot unilateral present a sub-certificate to the 530 client, instead, client will indicate to the user in clientHello 531 that it will support delegated credentials. The solution 532 obviously requires changes in the client and additional changes to 533 the issuance of certificate. Based upon the draft, it is not 534 clear whether sub-certificates can be cascaded (as noted in 535 section 5.1), that is, once a sub-certificate is issued to an 536 entity and whether it can further use mechanism to issue a sub- 537 certificate to the downstream CDN. 539 Currently, no single solution fits the cascaded CDNs approach alone. 540 As such, these solutions could be complementary to allow an end-to- 541 end delegation in CDNI. However, the work on these drafts are in 542 progress or in early stages and needs further work to provide an end- 543 to-end solution. 545 7. IANA Considerations 547 This document has no IANA considerations. 549 8. Security Considerations 551 The entire document is about security. 553 9. References 555 9.1. Normative References 557 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 558 DOI 10.17487/RFC2818, May 2000, 559 . 561 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 562 (TLS) Protocol Version 1.2", RFC 5246, 563 DOI 10.17487/RFC5246, August 2008, 564 . 566 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 567 Housley, R., and W. Polk, "Internet X.509 Public Key 568 Infrastructure Certificate and Certificate Revocation List 569 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 570 . 572 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 573 Authority Authorization (CAA) Resource Record", RFC 6844, 574 DOI 10.17487/RFC6844, January 2013, 575 . 577 9.2. Informative References 579 [ciscotraffic] 580 "The Zettabyte Era--Trends and Analysis", 2016, 581 . 585 [EricssonOOB] 586 "Ericsson BC drafts", 2016, 587 . 589 [I-D.cdni-fieau-lurk-https-delegation] 590 Fieau, F. and S. Emile, "Limited Use of Remote Keys for 591 Interconnected CDNs", draft-cdni-fieau-lurk-https- 592 delegation-00 (work in progress), July 2016. 594 [I-D.ietf-acme-caa] 595 Landau, H., "CAA Record Extensions for Account URI and 596 ACME Method Binding", draft-ietf-acme-caa-02 (work in 597 progress), June 2017. 599 [I-D.ietf-acme-star] 600 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 601 Fossati, "Use of Short-Term, Automatically-Renewed (STAR) 602 Certificates to Delegate Authority over Web Sites", draft- 603 ietf-acme-star-00 (work in progress), June 2017. 605 [I-D.ietf-httpbis-encryption-encoding] 606 Thomson, M., "Encrypted Content-Encoding for HTTP", draft- 607 ietf-httpbis-encryption-encoding-09 (work in progress), 608 April 2017. 610 [I-D.mglt-lurk-tls-use-cases] 611 Migault, D., Ma, K., Salz, R., Mishra, S., and O. Dios, 612 "LURK TLS/DTLS Use Cases", draft-mglt-lurk-tls-use- 613 cases-02 (work in progress), June 2016. 615 [I-D.reschke-http-oob-encoding] 616 Reschke, J. and S. Loreto, "'Out-Of-Band' Content Coding 617 for HTTP", draft-reschke-http-oob-encoding-12 (work in 618 progress), June 2017. 620 [I-D.rescorla-tls-subcerts] 621 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 622 "Delegated Credentials for TLS", draft-rescorla-tls- 623 subcerts-01 (work in progress), March 2017. 625 Authors' Addresses 627 Frederic Fieau (editor) 628 Orange 629 40-48, avenue de la Republique 630 Chatillon 92320 631 France 633 Email: frederic.fieau@orange.com 635 Emile Stephan 636 Orange 637 2, avenue Pierre Marzin 638 Lannion 22300 639 France 641 Email: emile.stephan@orange.com 643 Sanjay Mishra 644 Verizon 645 13100 Columbia Pike 646 Silver Spring MD 20904 647 USA 649 Email: sanjay.mishra@verizon.com