Network Working Group F. Fieau, Ed.
Internet-Draft E. Stephan
Intended status: Standards Track Orange
Expires: May 4, 2017 S. Mishra
Verizon
October 31, 2016
HTTPS delegation in CDNI
draft-fieau-cdni-https-delegation-00
Abstract
This document examines probable solutions for delegating of encrypted
content within the context of CDN interconnection. HTTPS delegation
allows a delivering party, e.g. a CDN, to deliver content for and on-
behalf of an origin server. The HTTPS delegation also expects
delivering content without compromising security, integrity and
privacy of the user. This document examines Internet Drafts that
have been submitted along with their implementation status.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Fieau, et al. Expires May 4, 2017 [Page 1]
Internet-Draft HTTPS delegation in CDNI October 2016
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. LURK for CDNI . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. uCDN Key Server (CDNI framework) . . . . . . . . . . . . 4
3.2. CSP Key server . . . . . . . . . . . . . . . . . . . . . 4
4. Out-of-Band for CDNI . . . . . . . . . . . . . . . . . . . . 5
4.1. OOB overview . . . . . . . . . . . . . . . . . . . . . . 5
4.2. OOB applied to CDNI . . . . . . . . . . . . . . . . . . . 6
5. Sub-certificates and Short-lived Certificates for CDNI . . . 7
5.1. SubCert Option 1a: Name Constraints . . . . . . . . . . . 8
5.2. SubCert option 1b: End Entities as Issuers . . . . . . . 9
5.3. SubCert option 2: new Structure . . . . . . . . . . . . . 10
5.4. SubCert option 3: Re-Use of the Master Certificate . . . 10
5.5. Short-lived certs use case for CDNI - ACME . . . . . . . 11
6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. LURK . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. OOB . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Subcerts and SLC . . . . . . . . . . . . . . . . . . . . 13
6.4. HTTPS delegation requirements . . . . . . . . . . . . . . 14
6.5. Implementation status . . . . . . . . . . . . . . . . . . 14
6.6. E2E HTTPS delegation for CDNs . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Currently, sixty percent of the HTTP traffic of the internet is
encrypted, that is, it is transported over TLS [RFC5246]. At the
same time, HTTP traffic served by CDNs is on the rise as well. The
traffic on CDNs is estimated to increase from forty-five percent in
2015 to seventy-five percent in year 2020 [ciscotraffic].
This document discusses viability of and solution for addressing
delegation of HTTP over TLS [RFC2818] traffic within the context of
CDN interconnection. HTTPS delegation allows delivering party, e.g.
a CDN, to deliver content for and on-behalf of an origin server.
Fieau, et al. Expires May 4, 2017 [Page 2]
Internet-Draft HTTPS delegation in CDNI October 2016
This draft considers three approaches for delegating HTTPS traffic in
a CDNI context. These include Limited Use of Remote Keys (LURK),
Out-of-Band, Short-Lived Certificates and Sub-Certificates (or
delegated credentials). We examine these approaches focusing on the
following three issues:
o Modification (or no) changes in the user agent
o Trust delegation (transitivity, that is, Is a CDN allowed to
delegate the trust it received directly from the Origin?)
o Maintain the user experience (privacy, integrity and performance)
To recap, CDNi goals, the CDNi WG focuses on the relationship between
the upstream CDN and the downstream CDN. Therefore, this document
examines HTTPS delegation with applicability to CDNi use cases and
particularly from an end-to-end perspective including the UA and the
Origin.
2. Terminology
o UA: User Agent
o CDNI: Content Delivery Network
o SLC: Short-Lived certificates
o LURK: Limited Use of Remote Keys
o dCDN: downstream Content Delivery Network
o uCDN: upstream Content Delivery Network
o CSP: Content Service Provider
o OOB: Out-of-Band
o PKS: Private Key Server
3. LURK for CDNI
[I-D.cdni-fieau-lurk-https-delegation] shows 2 use cases related to
CDN interconnection based on LURK [I-D.mglt-lurk-tls-use-cases]:
o uCDN Key Server: uCDN is authoritative on several origin domains.
Its key Server hosts certificates and private keys of these
origins. An interface between uCDN and dCDN allows dCDN to query
Fieau, et al. Expires May 4, 2017 [Page 3]
Internet-Draft HTTPS delegation in CDNI October 2016
credentials per session for these origins. Note that a dCDN is
typically connected to several uCDNs.
o CSP Key Server: a Content Service Provider is authoritative on
several origin domains. His key Server hosts certificates and
private keys for his domains. An interface between his key Server
and the dCDN allows the uCDN to query credentials for a given
session for these origins.
3.1. uCDN Key Server (CDNI framework)
dCDNs have an interface to a Key Server hosted at the uCDN side. It
may be typically a case of CDNI regional delivery delegation.
When the UA has been redirected from the uCDN to a dCDN,it initiates
a TLS connection with a dCDN cache to get his content. Since dCDN
cache does not store the private keys for the requested certificate,
it queries the uCDN Key Server (KS) to get credentials to establish
the TLS session. Finally the dCDN cache can deliver HTTPS content to
the UA using CSP certificate.
This framework makes 2 assumptions:
o The UA includes the Origin domain name in the SNI field of the TLS
ClientHello to enable a dCDN to select the other Key Server that
will generate credentials of the session by the KS of uCDN.
o The uCDN Key Server is provisioned with the certificate and the
private key for this Origin domain name.
3.2. CSP Key server
In this framework the CSP provides a Key Server for the origin
domains it is authoritative on to ensure an end-to-end HTTPS
delegation, from the Origin to the dCDN which eventually delivers the
HTTPS content to the UA. The CSP provides the LURK Key Server and
interface.
The CSP delegates the HTTPS content delivery to an uCDN that in turn
delegates the HTTPS delivery to a dCDN. The CSP provides the uCDN
with a Key Server interface to delegate the content delivery. In
that case, the dCDN relies on credentials received from a CSP Key
Server (KS) to deliver HTTPS content.
This framework supports 2 options:
o direct: The dCDN requests directly the CSP key server
Fieau, et al. Expires May 4, 2017 [Page 4]
Internet-Draft HTTPS delegation in CDNI October 2016
o cascaded: the dCDN session key requests are relayed by the uCDN to
the Key Server
4. Out-of-Band for CDNI
This section presents the usage of HTTP Out-of-Band mechanism
[I-D.reschke-http-oob-encoding] to deliver HTTPS content in CDNI.
4.1. OOB overview
Out-of-Band HTTPS content delivery (OOB) relies on the use of the
"out-of-band" value in "Accept-encoding" HTTP header of the request.
It indicates that the UA supports downloading the resource from
alternative locations than the Origin. To that purpose, when the
out-of-band content encoding is set, the Origin server may response
with a list of caches where to fetch the requested resource.
Example:
{sr: [{r:"https://ori/path/content1", r:"https://cdn1/path/content1"}]}
+----------+ +----------------+ +-------------+
| UA |--3) GET --->| cache |--4) GET---> |Origin Server|
+----+-----+ content +----------------+ content +----+--------+
| ^ | ^
| |---------- 2) 2OO OK, OOB + resource map-----------+ |
|--------------------- 1) HTTP GET content -------------------+
Figure 1: OOB general principle
Out-of-Band framework involves the following functional entities:
Origin server:
o OOB specifies the first step of the HTTPS delivery delegation: the
soft redirection toward alternative locations that Origin trusts
in a resource map.
o The Origin server receives new HTTP header value "accept-encoding"
and responses with a "content-encoding"
UA:
o must store resource map received from the Origin server
Fieau, et al. Expires May 4, 2017 [Page 5]
Internet-Draft HTTPS delegation in CDNI October 2016
o must support new HTTP header "accept-encoding" values to comply
with OOB
Cache server:
o has standard cache functions, and supports TLS for delivery and
content provisioning from origin.
o When the cache receives a request from the UA, it uses the "http
referer" of the request to know the origin url where to pull and
store the requested content.
4.2. OOB applied to CDNI
In CDNI, uCDN may use OOB to direct a UA to dCDN by indicating a
resource map where it can fetch contents. In CDNI, an end-to-end
delegation allows an Origin delegates HTTPS delivery to uCDN which in
turns delegates it to dCDN.
For instance, end-to-end delegation may involve cascaded resource
maps. The Origin delegates HTTPS delivery to the uCDN using OOB, and
uCDN delegates HTTPS delivery to dCDN through OOB. In that case, the
UA requests Origin that sends back a resource map pointing at the
uCDN. Then UA requests the uCDN which sends back a resource map
(OOB) pointing at dCDN hosted resources.
Fieau, et al. Expires May 4, 2017 [Page 6]
Internet-Draft HTTPS delegation in CDNI October 2016
User Agent dCDN uCDN Origin
| | | |
| GET http://origin/hash1/content | |
+----------------------------------------------------->|
| 200 OK + OOB | |
+<-----------------------------------------------------|
| GET http://ucdn/hash2/content | |
+------------------------------------>| |
| 200 OK + OOB | |
|<------------------------------------+ |
| | | |
|GET http://dcdn/hash2/content | |
+----------------->| | |
| | GET http://ucdn/hash2/content |
| |----------------->| |
| | 200 OK (encrypted content) |
| |<-----------------| |
| 200 OK (encrypted content) | |
|<-----------------+ | |
| | | |
figure 2: OOB with successive resource maps in CDNI
5. Sub-certificates and Short-lived Certificates for CDNI
The need to scale is a central requirement to generalize HTTPS
content delivery across CDNs. Both [I-D.rescorla-tls-subcerts] and
[I-D.sheffer-lurk-cert-delegation] share the same paradigm. They aim
to decouple credentials provisioning from content delivery.
The [I-D.sheffer-lurk-cert-delegation] cert architecture adds
interactions between the CDN and the Origin and between the Origin
and the CA which signs the limited authority delegation;
[I-D.sheffer-lurk-cert-delegation] certificate implementation
requires modifications of the UA, the cache and the origin. The
[I-D.rescorla-tls-subcerts] proposes an architecture where the TLS
server by itself can create a sub-certificate (also referred to as
"delegated credentials") based on the original certificate issued to
it by the CA. This sub-certificate's scope is only to the
credentials issued by the CA corresponding to the original
certificate and for the named servers the CA has authorized.
In case of CDNI, it is feasible that the uCDN may issue
"delegated_credentials" to a dCDN for any HTTPS content it delegates
to dCDN for delivery.
Fieau, et al. Expires May 4, 2017 [Page 7]
Internet-Draft HTTPS delegation in CDNI October 2016
This new "delegated certificate" will have a validity interval along
with the public key issued to the Content Service Provider (CSP) or
to its surrogate (CDN) by the CA and a list of valid server names.
Both solutions require changes to the user agent. The
[I-D.rescorla-tls-subcerts] draft proposes User Agent to send an
empty "delegated_credential" extension in its ClientHello.
5.1. SubCert Option 1a: Name Constraints
The proposal outlines an option where a CA can issue subordinate
certificate but with a nameConstraints extension with encoded names
the TLS server is authorized for in the original certificate. In
this approach, the credentials would just be equivalent of end-entity
certificates issued under the subordinate certificate. The use of
nameConstraints extension, will only work for clients that indicate
its support and will not work for clients that do not support
nameConstraints.
Based upon the Name Constraints option, the following two possible
use cases can be considered for CDNi:
o CA issues a subordinate certificate to CDN on behalf of the
Content Service Provider (CSP)
For a use case when the CSP does not authorizes CDN (uCDN) to request
CA on its behalf to request private keys and the certificate instead
it allows the CDN to request a subordinate certificate on its behalf.
In such a case, the CDN (uCDN) can request the CA for a subordinate
certificate. Based on this subordinate certificate request, the CA
can issue credentials with the nameConstraints extension encoding
using the names of servers uCDN would identify in its request to the
CA. In this scenario, we assume that CSP and uCDN have a business
relationship and an agreement that allows uCDN to request a sub-
certificate on behalf of the CSP. However, it is not clear from the
[I-D.rescorla-tls-subcerts] draft the scope of request can be
cascaded down from one CDN to another CDN, that is, from an uCDN to
dCDN. This needs further understanding on scope to request a sub-
certificate by one and more dCDN who may or may not have business
relationship with the CSP.
o uCDN issues a subordinate certificate to the dCDN
When the CSP allows CDN to procure a certificate from the CA on its
behalf, the uCDN can then issue a subordinate certificate with the
nameConstraints extension encoding for the names of server
(identified by dCDN to uCDN) in request for any HTTPS content that
uCDN shall delegate to dCDN to serve on its behalf. In this scenario
Fieau, et al. Expires May 4, 2017 [Page 8]
Internet-Draft HTTPS delegation in CDNI October 2016
we assume that dCDN provides all information regarding servers that
will be used for holding content for which uCDN will issue sub-
certificates to the dCDN.
5.2. SubCert option 1b: End Entities as Issuers
In this option, the [I-D.rescorla-tls-subcerts] draft proposes a
method where TLS server as an end-entity certificate holder can issue
a sub-certificate. This method however requires changes to how the
certificates are issued to an end-entity. A mechanism would be
needed to enable end-entity issue a sub-certificate. The
[I-D.rescorla-tls-subcerts] draft suggests defining a marker value
within an end-entity certificate as an indicator that it can issue
sub-certificates. The use of marker shall distinguish an existing
end-entity certificate holder who should not issue versus holder
(uCDN) of an end-entity certificate with a marker that can issue a
sub-certificate. Alternatively, the draft also suggests that a
marker can even be the fact that an end-entity certificate to not
contain KeyEncipherment KeyUsage (Refer to [RFC5280], section
4.2.1.3). KeyEncipherment bit can be used by older protocols such as
SSLv2, therefore, suggestion by authors is that mere absence of this
field not only prevents forging of signature but its absence
implicitly can also be an indicator and clients can refuse any
connections from certificates with with KeyEncipherment KeyUsage
field.
When applied to CDNi scenario, we consider following two cases:
o CSP as an End-entity Issuer
In this scenario, CSP does not share private keys and the certificate
with the CDN (uCDN), instead the CSP can issues a sub-certificate to
the uCDN. It is not clear from the [I-D.rescorla-tls-subcerts]
draft if the scope of request can be cascaded down from one CDN to
another CDN, that is, from an uCDN to dCDN. This needs further
understanding on scope to request a sub-certificate by one and more
dCDN who may or may not have business relationship with the CSP.
o CDN as an End-entity Issuer
In this scenario, a CSP allows its CDN provider to request on its
behalf the private keys and certificate from the CA. This allows a
uCDN as an end-entity certificate holder to issue a sub-certificate
for the dCDN. In this case, we assume the dCDN only requires prior
business agreements with the uCDN and does not require any business
agreements with the CSP.
Fieau, et al. Expires May 4, 2017 [Page 9]
Internet-Draft HTTPS delegation in CDNI October 2016
5.3. SubCert option 2: new Structure
The [I-D.rescorla-tls-subcerts] draft explores an option to allow
creating of new signed objects based on existing X.509 end-entity
certificates. The draft requires presence of digitalSignature bit of
the KeyUsage ([RFC5280], section 4.2.1.3) in the certificate to
create the new signed object. The drafts states that this approach
will require defining a new signed object format with encoding for
only the semantics needed for generation of new signed objects.
When applied to CDNi scenario, we consider the following two cases:
o CSP Issuing New Signed Object
In a scenario when the CSP does not authorize CDN (uCDN) the use of
its private keys and certificate, the CSP will need to issue a signed
object for use by uCDN. However, given that the uCDN does not hold
the original certificate, it may not be able to create another signed
object to cascade to a dCDN. Clarification is needed from the
[I-D.rescorla-tls-subcerts] authors on any further mechanism to allow
support for cascaded issuance of the sub-certs.
o CDN Issuing New Signed Object
In scenario the CSP authorizes CDN (uCDN) to request private keys and
certificate on its behalf from the CA. In this case, we expect that
uCDN can create a new signed object based on X.509 end entity
certificates using digitalSignature Key usage (RFC5280 section
4.2.1.3)
5.4. SubCert option 3: Re-Use of the Master Certificate
The [I-D.rescorla-tls-subcerts] draft proposes re-configuring the
certificate for use either as an end-entity certificate or to be used
for signing sub-certificates. Or, the master certificate can be
configured such that it in itself is not directly usable, rather the
name-holder to request two certificates. One such certificate can be
used for TLS authentication and second for signing credentials.
When applied to CDNi scenario, we consider the following case:
o Issuance of Master Certificate to the CDN
In this scenario, CSP authorizes CDN (uCDN) to request a master
certificate. As stated in the [I-D.rescorla-tls-subcerts] draft the
master certificate is not directly usable rather the master
certificate is issued as the CDN (uCDN) the name-holder. In this
scenario, the uCDN can delegate the signed credentials to the dCDN.
Fieau, et al. Expires May 4, 2017 [Page 10]
Internet-Draft HTTPS delegation in CDNI October 2016
However, as it is not the intent of [I-D.rescorla-tls-subcerts] to
consider CDNi uses, it does not discuss cascaded delegation,
therefore, it is not clear if TLS authentication certificate can be
conveyed to the dCDN. This will need clarifications from the
[I-D.rescorla-tls-subcerts] authors.
5.5. Short-lived certs use case for CDNI - ACME
[I-D.sheffer-lurk-cert-delegation] specifies an RESP API between the
uCDN and the CSP. It proposes a solution which provides the uCDN
with short term HTTPS delivery delegation.
Compared to per session key exchange, it decouples the credentials
provisioning from the content delivery to limit the burden on the CSP
side. It limits signaling to periodic short term certificate
requests (CSR) sent from the uCDN to the content owner:
o The uCDN requests a new sub certificate on the Origin REST API
using a POST;
o Then, the uCDN downloads the subcertificate and the associated
private key using a GET;
o The connection between dCDN and the Origin is mutually
authenticated.
The solution as currently proposed requires periodic requests from
the uCDN to procure keys and certificate.
The sub certificates cases describe above apply to Short lived
certificates. The CSP would also need to obtain a second certificate
with suitable keyUsage values for generating sub certificate. Both
Sub apply to a relation of delegation between a dCDN and uCDN.
The draft proposes an second architecture where the uCDN requests
directly the sub certificate to the CA using the ACME protocol. It
relies on the control by the content owner of URI based certificate
issuances based on the ACME protocol, using extensions
[I-D.ietf-acme-caa] to DNS CAA [RFC6844].
6. Discussions
6.1. LURK
A LURK interface may provide advantages to HTTPS delegation in CDNI
such as:
Fieau, et al. Expires May 4, 2017 [Page 11]
Internet-Draft HTTPS delegation in CDNI October 2016
o The origin of the information can be preserved, provided that DNS
is used to redirect a UA from the uCDN to a dCDN
o It mitigates the risks of CSP private keys leak by centralizing
them.
o It doesn't impact the UA nor TLS stack
o Revocation of delegation may be straightforward by denying any
access to private key server
However, preserving UX performances cannot be guaranteed as
additional RTT are needed to fetch the needed session credentials
from the Key Server.
6.2. OOB
OOB may provide advantages to HTTPS delegation in CDNI such as:
o CDNs can be agnostic of the cached contents; contents can actually
remain encrypted on the cache when HTTP encryption encoding
[I-D.ietf-httpbis-encryption-encoding] is used, which can be
valuable for the Content owner/provider.
o Origin URL stays unchanged in the address bar. So that Origin of
information is preserved.
However, the use of OOB to ensure HTTPS delegation in CDNI should be
clarified in many cases:
o Origin issue: how to preserve Origin in case of OOB chaining in
CDNI?
o How to improve OOB performance in E2E delegation, i.e., from the
Origin to dCDN, within a single OOB resource map received by the
UA?
o OOB for ensuring E2E delegation would raise delegation issues in
certain cases:
1. For instance, an E2E delegation using OOB with DNS redirect would
raise a delegation issue where the requested domain doesn't match the
URI which may trigger a warning on the UA. As such, delegation is
not solved (HARD problem).
The Origin delegates the delivery to uCDN with OOB, next the uCDN
delegates HTTPS delivery to a dCDN using DNS.In that case, the UA
requests origin that sends back a resource map pointing at uCDN, UA
Fieau, et al. Expires May 4, 2017 [Page 12]
Internet-Draft HTTPS delegation in CDNI October 2016
DNS then queries uCDN.com which is resolved to a dCDN server IP, the
UA requests contents on dCDN server
2. In another example, an E2E delegation using 302 redirect first
and OOB next, would raise a delegation issue where the origin of
information is the uCDN, not the Origin.
The Origin delegates HTTPS delivery to uCDN through a 302 redirect,
next uCDN delegates HTTPS delivery to dCDN using OOB. In that case,
the UA requests Origin who redirects it to the uCDN using 302 HTTP,
then UA requests the uCDN which answers OOB content pointing at dCDN,
then UA requests content on dCDN.
Finally, some clarifications about OOB draft are needed:
o How to avoid circular redirection
o Does the UA insert the out-of-band header in any request?
o Does the UA insert the out-of-band header when it requests a
resource it selected in a resource map it received in an "out-of-
band" response received from the origin?
6.3. Subcerts and SLC
The motivation of [I-D.rescorla-tls-subcerts] draft is to remove
dependency between the Origin Server or its surrogates and the CA
specifically for enabling the ability to issue credentials (sub-
certificates) under the authority of its own certificate and
importantly, manage lifetime of the certificates and also have the
ability to support any new cryptographic algorithms. The intent for
the authors is to give Origin Servers (or their surrogates)
operational independence when needing to either limit the life of a
certificate or when needing to issue a sub-certificate with limited
life. This process may be expeditious over needing to work with the
CA for either of the aforementioned changes while still preserving
the security and integrity of the content and communications between
the origin server or it's and surrogate and the client.
The [I-D.rescorla-tls-subcerts] draft explores several options to
allow origin server or its surrogate with capabilities to issue a
sub-certificate or delegated credentials with limited authority
(authorized name servers and a validity interval). The draft also
provides for ways where a client can control issuance of sub-
certificates. This control can be exerted by the clients by use of
an optional "delegated_credential" extension field in the
clientHello. The draft also calls out rules for its use, such as, a
Fieau, et al. Expires May 4, 2017 [Page 13]
Internet-Draft HTTPS delegation in CDNI October 2016
server cannot unilaterally send this extension but that it can only
send credentials when presented by the clientHello message.
However, as noted in sub-sections, 5.2 and 5.3, the applicability of
this draft may be limited in cascaded delegation that is from an up
stream CDN to the downstream CDN. Further clarity may be required
from the [I-D.rescorla-tls-subcerts] draft authors on ability to
cascade sub-certificates. The draft also lists pros and cons for
various options it considers in the draft. For brevity, those pros
and cons are not listed in this document.
The [I-D.sheffer-lurk-cert-delegation] and the
[I-D.rescorla-tls-subcerts] propose approaches where a TLS server,
i.e., a uCDN issue certificates or a sub-certificate with limited
authority and time without having to share a private key. The
approaches avoid any additional infrastructure cost and potential for
scaling up the solution. One of the key drawbacks with either
approach is additional changes required such as uCDN with content
owner and CA for [I-D.sheffer-lurk-cert-delegation]. Additionally, a
short-lived certificate creation system must be fully automated, as
manual renewal of certificates every few days is not practical. An
automated system requires require business relations and agreement
between the SP and CDN, and an initial setup. In case of
[I-D.rescorla-tls-subcerts], the proposal requires changes to TLS
handshake where the client provides an extension in its ClientHello
that indicates support for this mechanism.
6.4. HTTPS delegation requirements
Generic HTTPS delegations requirements that should be discussed:
o No changes in the client: delegation doesn't impact code on UA
side.
o No (or few) impacts on the CSP side: e.g. the load of signaling
introduced by the solution should be limited on CSP side
o Preserves the Origin of information: e.g., Origin URL in address
bar is preserved.
6.5. Implementation status
At the time being, LURK, OOB and subcerts are in early stage.
Currently SLC and subcerts are not available and need to be
clarified. However some prototypes already exists for OOB and LURK
[I-D.cairns-tls-session-key-interface] [EricssonOOB].
Fieau, et al. Expires May 4, 2017 [Page 14]
Internet-Draft HTTPS delegation in CDNI October 2016
6.6. E2E HTTPS delegation for CDNs
In order to ensure an end-to-end delegation from the Origin to dCDN,
a CDNI HTTPS delegation solution may combine several options
described in this document.
o LURK can allow the preservation of Origin of information, and
mitigates the risk of private CSP keys leakage. Regarding
performance, requesting a key server can lead to an increase in
Time To Service (Time to First Page) for UA but does not impact
downloading performances.
o OOB allows preserving origin URL while avoiding spreading of
private keys on CDN caches, but impacts UA. As far performance is
concerned, downloading successive resource maps and direct to the
requested resource can increase Time To Service (Time to First
Page), but still it does not impact content delivery performance.
o SubCerts: The motivation for sub-certificate
(delegated_credential) is to give an option to certificate holder
to create a sub-certificate and sign the credentials. The sub-
certificate shall have a validity interval and scope will be
limited to named servers. On top, the server cannot unilateral
present a sub-certificate to the client, instead, client will
indicate to the user in clientHello that it will support delegated
credentials. The solution obviously requires changes in the
client and additional changes to the issuance of certificate.
Based upon the draft, it is not clear whether sub-certificates can
be cascaded (as noted in sections 5.1 through 5.3), that is, once
a sub-certificate is issued to an entity and whether it can
further use mechanism to issue a sub-certificate to the downstream
CDN.
Currently, no single solution fits the cascaded CDNs approach alone.
As such, these solutions could be complementary to allow an end-to-
end delegation in CDNI. However, the work on these drafts are in
progress or in early stages and needs further work to provide an end-
to-end solution.
7. IANA Considerations
This document has no IANA considerations.
8. Security Considerations
The entire document is about security.
Fieau, et al. Expires May 4, 2017 [Page 15]
Internet-Draft HTTPS delegation in CDNI October 2016
9. References
9.1. Normative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification
Authority Authorization (CAA) Resource Record", RFC 6844,
DOI 10.17487/RFC6844, January 2013,
<http://www.rfc-editor.org/info/rfc6844>.
9.2. Informative References
[ciscotraffic]
"The Zettabyte Era--Trends and Analysis", 2016,
<http://www.cisco.com/c/en/us/solutions/collateral/
service-provider/visual-networking-index-vni/
vni-hyperconnectivity-wp.html]>.
[EricssonOOB]
"Ericsson BC drafts", 2016,
<https://github.com/EricssonResearch/Blind-Cache-Drafts>.
[I-D.cairns-tls-session-key-interface]
Cairns, K., Mattsson, J., Skog, R., and D. Migault,
"Session Key Interface (SKI) for TLS and DTLS", draft-
cairns-tls-session-key-interface-01 (work in progress),
October 2015.
[I-D.cdni-fieau-lurk-https-delegation]
Fieau, F. and S. Emile, "Limited Use of Remote Keys for
Interconnected CDNs", draft-cdni-fieau-lurk-https-
delegation-00 (work in progress), July 2016.
Fieau, et al. Expires May 4, 2017 [Page 16]
Internet-Draft HTTPS delegation in CDNI October 2016
[I-D.ietf-acme-caa]
Landau, H., "CAA Record Extensions for Account URI and
ACME Method Binding", draft-ietf-acme-caa-00 (work in
progress), October 2016.
[I-D.ietf-httpbis-encryption-encoding]
Thomson, M., "Encrypted Content-Encoding for HTTP", draft-
ietf-httpbis-encryption-encoding-03 (work in progress),
October 2016.
[I-D.mglt-lurk-tls-use-cases]
Migault, D., Ma, K., Salz, R., Mishra, S., and O. Dios,
"LURK TLS/DTLS Use Cases", draft-mglt-lurk-tls-use-
cases-02 (work in progress), June 2016.
[I-D.reschke-http-oob-encoding]
Reschke, J. and S. Loreto, "'Out-Of-Band' Content Coding
for HTTP", draft-reschke-http-oob-encoding-09 (work in
progress), October 2016.
[I-D.rescorla-tls-subcerts]
Rescorla, E., Barnes, R., Iyengar, S., and N. Sullivan,
"Delegated Credentials for TLS", draft-rescorla-tls-
subcerts-00 (work in progress), July 2016.
[I-D.sheffer-lurk-cert-delegation]
Sheffer, Y., "Delegating TLS Certificates to a CDN",
draft-sheffer-lurk-cert-delegation-00 (work in progress),
May 2016.
Authors' Addresses
Frederic Fieau (editor)
Orange
40-48, avenue de la Republique
Chatillon 92320
France
Email: frederic.fieau@orange.com
Emile Stephan
Orange
2, avenue Pierre Marzin
Lannion 22300
France
Email: emile.stephan@orange.com
Fieau, et al. Expires May 4, 2017 [Page 17]
Internet-Draft HTTPS delegation in CDNI October 2016
Sanjay Mishra
Verizon
13100 Columbia Pike
Silver Spring MD 20904
USA
Email: sanjay.mishra@verizon.com
Fieau, et al. Expires May 4, 2017 [Page 18]