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]