Internet DRAFT - draft-fieau-https-delivery-delegation
draft-fieau-https-delivery-delegation
Internet Engineering Task Force F. Fieau
Internet-Draft Orange
Intended status: Standards Track March 21, 2016
Expires: September 22, 2016
HTTPS and delegation of encrypted traffic between interconnected CDNs
draft-fieau-https-delivery-delegation-02
Abstract
This document discusses approaches to the issue of correct delegation
of the encrypted TLS-based traffic requests between CDNs in inter CDN
networks and during interactions between client User Agents (UA), and
Content Delivery Networks (CDNs).
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 September 22, 2016.
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
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.
Fieau Expires September 22, 2016 [Page 1]
Internet-Draft HTTPS delivery delegation March 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Redirection methods . . . . . . . . . . . . . . . . . . . . . 3
3.1. HTTP-based redirection methods . . . . . . . . . . . . . 4
3.1.1. 3xx directives . . . . . . . . . . . . . . . . . . . 4
3.1.2. URL Rewriting . . . . . . . . . . . . . . . . . . . . 5
3.1.3. API Mode, or scripted redirection . . . . . . . . . . 5
3.2. DNS redirection . . . . . . . . . . . . . . . . . . . . . 6
4. Use of Lurk interfaces for CDNI . . . . . . . . . . . . . . . 7
4.1. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 8
4.3. Discussions . . . . . . . . . . . . . . . . . . . . . . . 12
5. CDNI URI Signing . . . . . . . . . . . . . . . . . . . . . . 13
6. Topology hiding . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
In the interconnected CDNs context where CDNs are organized into a
hierarchy, an upstream CDN (uCDN) that is not able to deliver the
requested content for some reasons, may need to delegate the delivery
to a downstream CDN (dCDN). When end-users' connections are
transported over TLS, this delivery delegation involves security
requirements that are presented in the requirements section.
A brief survey indicates that there is a multitude of ad hoc
approaches for handling TLS-based traffic in CDN environment.
However, many of the currently adopted practices seem to have
problems of various nature, inhibiting and compromising security,
scalability, and ease of operation and maintenance (see e.g.
[HTTPS-CDN] and [SSL-Challenges]).
This document is intended as a starting point for discussion. It
shall review redirection methods introduced in [RFC3568] used in the
Interconnected CDNs use case, their impacts on the security of
delegation, and the implications of redirection in a secured web
environment. It eventually identifies some workarounds, or solutions
to the raised issues.
Fieau Expires September 22, 2016 [Page 2]
Internet-Draft HTTPS delivery delegation March 2016
2. Requirements
A trusted and secured delegation of the delivery of content hosted by
an uCDN to a downstream CDN (dCDN) must be guaranteed in the CDN
interconnection. Actually, this requirement must entail the
following:
o Legitimacy of redirection: the uCDN must wilfully designate the
dCDN to deliver the requested content to ensure the delegation is
legitimate. End-users must be warned about any issues in the
delegation process, e.g. bad certificate. This is typically
ensured by the browser (or player).
o Revocation use case: A revocation might occur when a dCDN is not
trusted anymore by the uCDN in case of policy or security
concerns, i.e. the dCDN surrogates has unsolved security issues,
or the delegation of HTTPS content delivery for a particular CP
has been terminated. For instance, in case of revocation, a dCDN
must not be able to present the CP or uCDN certificate to the user
agent when UA has directly requested a content to the dCDN.
o CDN configuration/topology visibility: Reduce CDN configuration,
topology and meta-data disclosure/visibility towards the end-
users. This means to keep this information hidden from each CDNs,
and from the end-user browser. As an example, the end-user shall
not be aware of the CDNI topology; this may imply for instance to
remove data in the redirection messages.
3. Redirection methods
In a secured CDN interconnection where uCDN and a dCDN have two
distinct domains, the User Agent (UA) tries first to resolve the uCDN
domain when it contacts the uCDN for a piece of content. At this
step, two types of redirection methods can be considered, both
delegating the content delivery to the dCDN (please refer to
[I-D.ietf-cdni-redirection]):
o using an HTTP-based mechanism, the UA is redirected by the uCDN to
the dCDN. Once the uCDN domain is resolved, the UA negotiates a
secured connection to the uCDN for that content, and receives the
uCDN certificate. Then the uCDN subsequently uses an HTTP
redirection method to redirect the UA to a dCDN surrogate content
server. Then, the UA resolves the dCDN domain name.
o using DNS routing, the UA is redirected to the dCDN, e.g., with a
CNAME sent by the uCDN's authoritative DNS server.
Fieau Expires September 22, 2016 [Page 3]
Internet-Draft HTTPS delivery delegation March 2016
Next the UA negotiates a new secured connection with the dCDN,
retrieving the dCDN certificate. If the certificate is valid, then
the UA will be able to connect to the dCDN surrogate, and the dCDN
will deliver the requested piece of content to the UA.
3.1. HTTP-based redirection methods
This section deals with HTTP-based redirection methods for secured
TLS connections in CDNI.
3.1.1. 3xx directives
When dealing with redirection over HTTP/S, two sub-cases should be
considered:
o HTTP -> HTTPS: In this case, the CSP / uCDN from domain A
redirects end-users' HTTP requests to the dCDN from domain B, and
upgrades the security scheme to HTTPS.
o HTTPS -> HTTPS: In this case, the CSP / uCDN domain A redirects
the browsers' request to dCDN domain B.
Regardless of DNS resolution aspects, in the first sub-case, the
initial delegation will not be secured, or trusted: the end user will
have no cryptographic assurance that the uCDN is delegating to that
dCDN, even though the user may subsequently form a secure connection
to the dCDN. The HTTPS upgrade should always be accepted
automatically by the browser, on the condition that the certificate
is valid and trusted (e.g., not self-signed).
In the second sub-case, the TLS handshake happens before the first
HTTP request is sent, therefore, the subsequent traffic including
request URI and query parameters will be encrypted. First, the TLS
session is established between the UA and the origin uCDN,
authenticating the uCDN. Then, the uCDN uses HTTP mechanisms for
redirection, using 3xx messages like 302 Found, embedding the new
target URI aiming at the CDN surrogate in the Location header. The
UA then sets up a separate TLS session with the dCDN surrogate,
validating the dCDN certificate. Trust relationship is implied since
the redirection message has been received over the authenticated TLS
tunnel with the origin uCDN.
The delegation is trusted and legitimate even if two independent TLS
sessions will have to be set up in sequence by the UA. Indeed, when
tying two sessions together, the authenticated origin uCDN
communicates the target URI in the redirection message over an
encrypted tunnel, which constitutes a trust delegation endorsement.
Fieau Expires September 22, 2016 [Page 4]
Internet-Draft HTTPS delivery delegation March 2016
However the issue here is when a uCDN invalidates the delegation to
dCDN for some reasons. The dCDN will then still be able to stream
the content with a valid certificate if an end-user directly requests
content to it.
However, mainstream browser implementations support seamless secure
redirection via HTTP 3xx responses. Ultimately, the secure
delegation from a uCDN to a dCDN is entirely tractable in the HTTPS
environment provided that application layer redirection such as HTTP
3xx responses is used.
3.1.2. URL Rewriting
URL rewriting is a method to compute in a web page destination URLs
to point at new web location while this page is rendered on the
browser. This modification could typically be caused by a script
embedded in the page. Alternatively, a server-side code could modify
embedded URLs before the page is retrieved by a browser, including
certain classes of web intermediaries. URL rewriting can therefore
serves as a form of application-layer redirection.
Regarding CDNI, a page served over TLS by an uCDN will prevent
intermediaries from modifying URLs without the consent of the user or
the uCDN. Client-side scripts pushed by the uCDN will still be
secure, and then the redirection to any dCDNs via rewriting would be
secure as well.
In the case of HTTP Adaptive Streaming (HAS) techniques where content
is chunked in order to be played with multiple video qualities, a
manifest file will describe the way the content was prepared/encoded,
e.g. how many qualities, chunks size, and their network location.
This manifest is requested by the player prior to any chunks.
Regarding CDNI, if the manifest is available on the uCDN domain A,
while video chunks are available on the dCDN domain B, the player
requesting for chunks will be redirected by the uCDN to the dCDN
using 3xx redirection methods (see the previous section).
In another more complex case, both the uCDN and the dCDN may deliver
some of the video chunks.
3.1.3. API Mode, or scripted redirection
In the API mode (e.g. via AJAX requests, JSONP, etc.), a web page
requested by the browser contains a script that "transparently" -
from the user's perspective - requests content on another web page.
Fieau Expires September 22, 2016 [Page 5]
Internet-Draft HTTPS delivery delegation March 2016
As far as CDNI is concerned, the initial web page and scripts would
be located on domain A, whereas content requested by the script would
be located on a secondary domain B.
Apart from "cross-domain" (CORS) issues that can be fixed with an
"Access-Control-Allow-Origin" header, this use case raises also the
security issues likewise in other HTTP-based redirection cases.
3.2. DNS redirection
In the case of DNS-based redirection, prior to any HTTP delivery
requests, the UA has to first resolve the uCDN domain, then uCDN DNS
server answers with the dCDN domain name (e.g., using a CNAME)
instead of the uCDN domain, thus realizing the DNS redirection to the
dCDN.
In that case, the redirection happens before the establishment of the
TLS tunnel. The issue here is that the user UA expects the uCDN's
certificate, but instead obtains the dCDN surrogate's certificate
during the TLS handshake. Mismatch between the expected origin uCDN
URI and the received dCDN domain designated in the obtained
certificate causes certificate validation warnings at the UA.
Eventually a client UA displays a warning to the end user requiring
additional steps, which may compromise the delegation security.
The CDNI Redirection draft ([I-D.ietf-cdni-redirection]) specifies
that in addition to HTTP, DNS redirection can be used as a means of
delegation from a uCDN to a dCDN. In this case, upon querying the
hostname associated with the uCDN URL, the DNS resolver will receive
a DNS response (such as CNAME) that will direct the client to the
dCDN. However, in an HTTPS environment, the client will end up with
a domain different than the one originally specified by the URL input
by the end user. Consequently, this will result in a security
failure when the browser attempts to negotiate TLS with the web
server it contacts, as the change in domain name will be
indistinguishable from a malicious attacker.
Another security related to the "HARD problem" draft
[I-D.barnes-hard-problem] ("High Assurance Re-Direction") is where a
malicious DNS resolver could return DNS responses (IP addresses/
CNAMEs) that steer the User Agent to a malicious server. DNS
response hijacking could be used to mount a DoS attack against the
CDN/Content Provider as the User Agent won't be able to receive the
content that it wants because it is being told to retrieve it from a
server that it can't establish a TLS session to.
DNSSEC would prevent that because responses would need to be signed
and a malicious DNS resolver would therefore not be able to return
Fieau Expires September 22, 2016 [Page 6]
Internet-Draft HTTPS delivery delegation March 2016
malicious responses as it would not be able to generate properly
signed DNS response.
DNSSEC makes it possible to secure DNS redirections. Were CDNI to
use DNSSEC for DNS based redirection, the client's resolver would
have a strong assurance that the uCDN had explicitly designated the
dCDN as its delegate. However, DNSSEC adoption remains limited, and
consequently this may not be a practicable solution in the immediate
future. While technologies like DANE which build on DNSSEC could
help, they remain dependent on DNSSEC adoption.
4. Use of Lurk interfaces for CDNI
Delegating the delivery of HTTPS traffic to a third party without any
certificate issues can be achieved if the dCDN surrogate is able to
present the security credentials for the domain name in the user's
initial request.
One of the common practices so far has been for the content provider
to directly delegate the storage of the private keys to the CDN that
is delivering the content on its behalf. This solution could persist
in the CDNI context, but in a scenario where delivery is done through
multiple cascaded dCDN, it becomes unlikely that the content provider
would be willing to share its private keys with all the parties
involved and breaks the delegation revocation use cases.
The proposed solution here relies on the introduction of a Private
Key Server in the TLS handshake as described in the Lurk draft
[I-D.mglt-lurk-tls-use-cases] that suggests several use cases of
private key server and protocols implementation.
Some solutions implementing private Key Servers are being
standardized. For instance, the Session Key interface - SKI - draft
[I-D.cairns-tls-session-key-interface] shows an example of Lurk
interface implementation. Others are commercially deployed and are
made publicly available.
A Lurk interface implementation for CDNI would allow the private keys
to remain under the authority of the content provider (or the uCDN)
while the actual content would be served from a dCDN surrogate that
is closer to the end user. Indeed, the architecture would introduce
a split in the setup of the secure tunnel between the client's
browser and the surrogate delivering the content. Since the dCDN
would not possess the private keys for the requested certificate,
during the setup of the TLS tunnel between the client and the dCDN
surrogate. The dCDN would in turn forward a request to get the
necessary credentials to establish the secure connection to the end-
user and serve the content.
Fieau Expires September 22, 2016 [Page 7]
Internet-Draft HTTPS delivery delegation March 2016
Note that a Lurk interface would allow provisioning certificates to
the dCDN and avoids any private keys exchanges between uCDN and the
dCDN involved in the delegation. The implementation of Lurk need to
be used jointly with DNS redirection.
4.1. Use cases
Two main use cases shall be considered when implementing Lurk in the
CDNI context:
a. "Nominal" case for HTTPS delegation: a uCDN delegates the HTTPS
content delivery to a dCDN without providing with its private
keys for legal/trusting issues. In this case, only the uCDN
would need a valid certificate, whereas the dCDN would rely on
session key received from the uCDN Key Server (KS) for the TLS
session establishment. Therefore the dCDN will deliver HTTPS
content using the uCDN certificate.
b. Cascaded HTTPS delivery delegation: This use case has a wider
scope that the previous use case. In the context, the content
provider delegates the HTTPS content delivery of his content to
an uCDN, that in turn delegates the HTTPS delivery to a dCDN.
For security reasons, the CP do not want to provide his private
keys to all CDNs involved in the interconnection hierarchy. In
that case, the uCDN and all dCDN will rely on the CP private keys
received from a Key Server (KS) on CP side to deliver HTTPS
content.
4.2. Implementation
This section describes basic implementations of Lurk for CDNI secured
traffic delegation (case a.). In the following example, the CP has
provided his certificate to the uCDN.
As seen on figure 2, once the DNS resolution is done (i.e., UA is
able to resolve dCDN surrogate IP@ steps a to d), the user agent
connects to the dCDN surrogate. Also please note that DNS cache
is not shown on the figure.
1. The client sends a ClientHello, as defined in the TLS protocol
[RFC5246].
2. The surrogate sends a ServerHello.
3. The surrogate sends the public certificate to the user agent.
The user agent checks the certificate signature with the public
key.
Fieau Expires September 22, 2016 [Page 8]
Internet-Draft HTTPS delivery delegation March 2016
In order to prepare the certificate delegation, it may be
necessary to provision CP public certificates hosted on the Key
Server, on uCDN or CP side, to the dCDN that will be requested the
content. Please refer to fig. 3. A request is sent by the dCDN
to uCDN KS to get the CP Public certificate.
4. The surrogate requests the key server to sign parameters with
the private key.
5. The key server returns the signature to the dCDN surrogate
over a secure tunnel.
6. and 7. the client and the surrogate exchange public DH
parameters and compute session keys.
8. The end-user terminal and the surrogate establish a secure
connection. The user agent issues its request for content over
HTTPS.
The surrogate then processes the original request.
Below is an example of the handshake establishment:
Fieau Expires September 22, 2016 [Page 9]
Internet-Draft HTTPS delivery delegation March 2016
+----+ +----+ +-------+ +----+
| UA | |dCDN| |uCDN KS| |uCDN|
+----+ +----+ +-------+ +----+
|a. DNS A? FQDN CP | | |
|---------------------------------------------------------------->|
| | | |
|b. DNS CNAME dCDN | | |
|<----------------------------------------------------------------|
| | | |
|c. DNS A? dCDN | | |
|------------------->| | |
| | | |
|d. DNS A IP Surrogate | |
|<-------------------| | |
| | | |
|1. ClientHello (Client Random) | |
|------------------->| | |
| | | |
|2. ServerHello (Server Random) | |
|<-------------------| | |
| | | |
|3. Certificate (Server certificate) | |
|<-------------------| | |
| | | |
| |4. API request for Signature (ECDHHParams) |
| |------------------>| |
| | | |
| |5. API response: signature (ECDHHParams) |
| |<------------------| |
| | | |
|6. ServerKeyExchange (ECDHParams, Signature) |
|<-------------------| | |
| | | |
|7. ClientKeyExchange (clientDHpublic) | |
|------------------->| | |
|Finished | | |
|<------------------>| | |
| | | |
|8. HTTPS request | | |
|------------------->| | |
Figure 2: Overview of Lurk interface with DH handshake in case of
regional delivery delegation
As shown on figure 4, a similar implementation can be considered for
RSA keys handling.
Fieau Expires September 22, 2016 [Page 10]
Internet-Draft HTTPS delivery delegation March 2016
Note that next after step 1, the dCDN may have to retrieve [at least
once] the CP public certificate related to the targeted FQDN. This
could be done using specific API methods dedicated to certificate
retrieval. The certificates may be cached on the dCDN for a given
duration. See next figure.
This Lurk API may have to support both RSA (cf. figure 4) and/or
Diffie-Helman (cf. figure 2) connection setup.
+----+ +----+ +-------+ +----+
| UA | |dCDN| |uCDN KS| |uCDN|
+----+ +----+ +-------+ +----+
| | | |
|1. ClientHello (Client Random) | |
|------------------->| | |
| | | |
| |a. API: Request FQDN CP public certificate |
| |------------------>| |
| | | |
| |b. API: CP Public certificate (cacheable) |
| |<------------------| |
| ... | | |
Figure 3: Optional steps for a dCDN to get the uCDN public
certificate (public certificates may be cached on the dCDN for a
given duration)
Fieau Expires September 22, 2016 [Page 11]
Internet-Draft HTTPS delivery delegation March 2016
+----+ +----+ +-------+ +----+
| UA | |dCDN| |uCDN KS| |uCDN|
+----+ +----+ +-------+ +----+
|a. DNS A? FQDN CP | | |
|---------------------------------------------------------------->|
| | | |
|b. DNS CNAME dCDN | | |
|<----------------------------------------------------------------|
| | | |
|c. DNS A? dCDN | | |
|------------------->| | |
| | | |
|d. DNS A IP Surrogate | |
|<-------------------| | |
| | | |
|1. ClientHello (Client Random) | |
|------------------->| | |
| | | |
|2. ServerHello (Server Random) | |
|<-------------------| | |
| | | |
|3. Certificate (Server certificate) | |
|<-------------------| | |
| | | |
|4. ClientKeyExchange (Encrypted Premaster Secret) |
|------------------->| | |
| |5. API request for Signature + decrypt premaster secret
| |------------------>| |
| | | |
| |6. API response: signature |
| |<------------------| |
| | | |
|Finished | | |
|<------------------>| | |
Figure 4: Overview of Lurk implementation with RSA in case of
regional delivery delegation
4.3. Discussions
o HTTPS: currently, the contents are delivered with the credentials
of uCDN or dCDN. The introduction of a key server in the CDNI
architecture allows the HTTPS content to be delivered with the
origin server certificate. It conforms to the end-to-end HTTPS
framework [RFC2818].
Fieau Expires September 22, 2016 [Page 12]
Internet-Draft HTTPS delivery delegation March 2016
o TLS: it does not significantly impact the TLS session
establishment duration, while benefiting from TLS session
resuming.
o Certificates: a certificate per CP would be stored and managed by
the uCDN (or the CP) in a private KS is needed for the CDNI.
Therefore it avoids the complexity of having multiple certificates
and domain names, e.g. one domain name per CDN of the
interconnection. As a side effect, it could also prevent
certificates mismatches and help warning the user at user agent
side, while ensuring the legitimacy of redirection.
o Security: the dCDN has never access to the uCDN (or CP) private
keys, as it rely on the uCDN (or CP) certificate to setup the
connection.
o Revocation: in the case of an HTTPS delegation revocation, a dCDN
has no longer the delegation right to deliver a content for a
given CP. The uCDN would then deny access to CP certificates, and
therefore the dCDN would not be able to present the CP certificate
to the UA.
o RSA: the use of RSA scheme is not recommended as the UA needs to
share premaster secret key which can be a security flaw.
o Use cases: other use cases, e.g. the dCDN would manage its own
keys/cert in a Key Server that would be requested by the uCDN,
will be described in a further version of this draft.
5. CDNI URI Signing
Another means of enforcing trust delegation would be to use CDNI URI
Signing mechanism. The CDNI URI Signing [I-D.leung-cdni-uri-signing]
draft specifies a detailed mechanism to ensure the validation of
parameters communicated in the redirection URI.
Considering CDNI and HTTPS delegation, this URI signing mechanism
could be used as means to enforce trust delegation.
While this later draft focuses on the validation by the target CDN of
the authenticity of the parameters communicated in the redirect URI
generated by the origin CSP, CDNI URI Signing mechanism could be
extended or used to include the certificate information or hashes
either in the provided URI Signing Package Attribute, or in an
additional Package Attribute (e.g. Redirect Authentication
Attribute), reusing much of the mechanisms detailed in the draft.
Fieau Expires September 22, 2016 [Page 13]
Internet-Draft HTTPS delivery delegation March 2016
6. Topology hiding
A further security concern associated with redirection is the
question of how much information a uCDN imparts to the browser, and
consequently to the end user, about its policy decisions in
delegating to a dCDN. However, in order to preserve crucial security
properties, it is likely unavoidable that a certain amount of
information will be divulged to any browser or client of a CDN
system. For example, consider that eventually, content will be
downloaded from a dCDN cache at a particular IP address, and that
consequently, information about a responsible network will always be
revealed to an end user.
The guidance in [I-D.ietf-cdni-redirection] Section 5 considers the
possibility of using "probes" of this form, and the potential
topology leakage of any redirection interface.
7. IANA Considerations
This document has no IANA considerations.
8. Security Considerations
The entire document is about security.
9. Acknowledgments
The authors would like to thank Iuniana Oprescu and Sergey Slovetskiy
for the initial authoring of this draft.
Many thanks also to Jon Peterson, Jan Seedorf, and Ben Nivens-Jenkins
for their help in putting this draft together.
10. References
10.1. Normative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms",
RFC 3568, DOI 10.17487/RFC3568, July 2003,
<http://www.rfc-editor.org/info/rfc3568>.
Fieau Expires September 22, 2016 [Page 14]
Internet-Draft HTTPS delivery delegation March 2016
[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>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>.
10.2. Informative References
[HTTPS-CDN]
J. Liang, J. Jiang, H. Duan, K. Li, T. Wan, and J. Wu,
"When HTTPS Meets CDN: A Case of Authentication in
Delegated Service", in 2014 IEEE Symposium on Security and
Privacy (SP), 2014, pp. 67-82..
[I-D.barnes-hard-problem]
Barnes, R. and P. Saint-Andre, "High Assurance Re-
Direction (HARD) Problem Statement", draft-barnes-hard-
problem-00 (work in progress), July 2010.
[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.ietf-cdni-redirection]
Niven-Jenkins, B. and R. Brandenburg, "Request Routing
Redirection interface for CDN Interconnection", draft-
ietf-cdni-redirection-17 (work in progress), February
2016.
[I-D.leung-cdni-uri-signing]
Leung, K., Faucheur, F., Downey, B., Brandenburg, R., and
S. Leibrand, "URI Signing for CDN Interconnection (CDNI)",
draft-leung-cdni-uri-signing-05 (work in progress), March
2014.
[I-D.mglt-lurk-tls-use-cases]
Migault, D. and K. Ma, "TLS/DTLS Content Provider Edge
Server Split Use Case", draft-mglt-lurk-tls-use-cases-00
(work in progress), January 2016.
Fieau Expires September 22, 2016 [Page 15]
Internet-Draft HTTPS delivery delegation March 2016
[Proposed_Lurk_Charter]
Eric Burger, "Proposed Lurk Charter",
<https://mailarchive.ietf.org/arch/msg/lurk/
tJBcaRJlYBGaOe1X6Hsc-smt4OU>.
[SSL-Challenges]
J. Clark and P. C. van Oorschot, "SoK: SSL and HTTPS:
Revisiting Past Challenges and Evaluating Certificate
Trust Model Enhancements", in 2013 IEEE Symposium on
Security and Privacy (SP), 2013, pp. 511-525.
Author's Address
Frederic Fieau
Orange
38-40 rue du General Leclerc
Issy-les-Moulineaux 92130
FR
Email: frederic.fieau@orange.com
Fieau Expires September 22, 2016 [Page 16]
