HTTPS and delegation of encrypted traffic between interconnected CDNs
draft-fieau-https-delivery-delegation-00

Internet Engineering Task Force                            F. Fieau, Ed.
Internet-Draft                                                I. Oprescu
Intended status: Standards Track                                  Orange
Expires: January 7, 2016                                    July 6, 2015

 HTTPS and delegation of encrypted traffic between interconnected CDNs
                draft-fieau-https-delivery-delegation-00

Abstract

   This document illustrates some use cases and associated problems
   related to delivery of HTTPS secured traffic in the context of
   interconnected CDNs.  A common scenario is when a uCDN is delegating
   the delivery of encrypted traffic to a dCDN using HTTP or DNS
   redirection.  Some potential solutions are considered.

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 January 7, 2016.

Copyright Notice

   Copyright (c) 2015 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 & Oprescu          Expires January 7, 2016                [Page 1]
Internet-Draft          HTTPS delivery delegation              July 2015

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  HTTP Request Redirection  . . . . . . . . . . . . . . . . . .   2
   3.  URL Rewriting . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  URL Rewriting for Video Contents  . . . . . . . . . . . .   4
   4.  API Mode  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  DNS Request Redirection . . . . . . . . . . . . . . . . . . .   4
   6.  Topology hiding . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Existing solutions  . . . . . . . . . . . . . . . . . . . . .   5
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   CDNI deals with contents stored on hierarchical CDNs.  An end user
   browser might request a particular piece of content from a uCDN, and
   if the uCDN cannot serve the content, it may redirect the request to
   a dCDN.  Because the uCDN trusts the dCDN to deliver the content,
   this delegation should ideally not trigger a security warning in the
   user's browser.

   This draft shall review some methods of redirection used in the field
   today, their impacts on the security of delegation, in the
   Interconnected CDNs use case, and the implications of redirection in
   a web environment that has transitioned entirely to HTTPS.

   This document currently addresses three HTTP redirection techniques
   as well as one DNS redirection method employed in CDNs today:

      HTTP 3xx redirect

      URL rewriting

      API mode, or scripted redirection (e.g. via AJAX requests, JSONP,
      etc.)

      DNS-layer redirection

2.  HTTP Request Redirection

   In this use case, the browser asks for a piece of ontent on a server,
   and the HTTP server replies with a "302 temporarily moved" message
   with a Location header field value containing the chosen content URL.

Fieau & Oprescu          Expires January 7, 2016                [Page 2]
Internet-Draft          HTTPS delivery delegation              July 2015

   In the CDNI case, we have to distinguish two sub-cases when dealing
   with redirections and HTTPS:

   o  HTTP -> HTTPS: In this case, the uCDN domain A redirects end-
      users' HTTP requests to the dCDN domain B, and upgrades the
      security scheme to HTTPS.  In this case, the initial delegation
      will not be secured; 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.

   o  HTTPS -> HTTPS: In this case, the uCDN domain A redirects the
      browsers' request to dCDN domain B.  The browser forms an initial
      TLS connection to domain A, receives a secure delegation, and then
      forms a new security association with domain B.

   In the first case above, 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 case, the delegation is secure.  Browser implementation
   determines how transparent the delegation may be to an end user.  If
   a browser generates a warning message notifying a of secure domain
   change, that would be problematic.  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.  URL Rewriting

   In some cases, when a web page is rendered on the browser side,
   embedded URLs in the page are modified in order to point at new web
   locations.  This modification is typically caused by a script
   embedded in the page.  Alternatively, a server-side script of some
   kind could modify embedded URLs before the page is retrieved by a
   browser, including certain classes of web intermediaries.  URL
   rewriting can therefore serve as a form of application-layer
   redirection, effectively.

   As far as CDNI is concerned, provided that the page and the script
   are served over TLS, then this will prevent intermediaries from
   modifying URLs without the consent of the user or the uCDN, but
   client-side scripts pushed by the uCDN will still be secure, and then
   the redirection to any dCDNs via rewriting this case would be secure
   as well.

Fieau & Oprescu          Expires January 7, 2016                [Page 3]
Internet-Draft          HTTPS delivery delegation              July 2015

3.1.  URL Rewriting for Video Contents

   A specific case concerns the HTTP Adaptive Streaming (HAS) video
   contents.  In this case, contents are chunked in order to be played
   with multiple available video qualities.  To do that, a manifest file
   is required to describe the way the contents was prepared/encoded,
   e.g. how many qualities, chunks size, and their network location.
   The manifest file shall requested by the player prior to any chunks.

   Regarding CDNI, in one case the manifest could be available on the
   uCDN domain A, while video chunks are available on the dCDN domain B,
   thus making a transparent redirection.  In a second, more complex
   case, both the uCDN and the dCDN may deliver some of the video
   chunks.

   When using HTTPS, concerns arise in both cases: if the manifest is
   rewritten insecurely, then

4.  API Mode

   In the API redirection mode, the web page requested by the browser
   contains a script that "transparently" (not strictly from the
   browser's perspective) requests contents on another Web page.

   As far as CDNI is concerned, the initial web page would be located on
   domain A, whereas contents requested by the script would be located
   on a secondary domain B.

   Apart from "cross-domain" (CORS) issues that can be easily fixed with
   an "Access-Control-Allow-Origin" header, this use case raises also
   the HTTPS certificate issues likewise the first two use cases.

5.  DNS Request Redirection

   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, the DNS resolver,
   when it queries for the hostname associated with the uCDN URL, will
   be served a DNS response (such as CNAME) that will direct the client
   to the dCDN.  However, in an HTTPS environment, this will result in
   the client containing a domain other than the one originally
   specified by the URL inputted by the end user.  Consequently, this
   will almost certainly 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.

Fieau & Oprescu          Expires January 7, 2016                [Page 4]
Internet-Draft          HTTPS delivery delegation              July 2015

   This poses serious concerns about the use of DNS as a redirection
   method when HTTPS is expected for CDNI use cases.

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.  This may tempt us to develop solutions that do
   not rely on a uCDN delegating via a redirection mechanism, either at
   the HTTP or the DNS layer.  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.  Existing solutions

   The problem CDNI faces with secure redirection in a pure HTTPS world
   is very similar to a set of known problem with secure redirection in
   the application layer.  For example, [I-D.barnes-hard-problem] covers
   this question based on the experience of implementing comparable
   secure redirection systems in personal messaging.  Any case where the
   client specifies an original domain name, and excepts to forge a
   security association a server holding a credential corresponding to
   that original domain name, will face certain difficulties when
   redirection is performed outside of the application layer, for
   example, in the DNS.  There are several known ways to address this
   problem, though none is perfect.

   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 in fact designated the dCDN
   as its delegate.  However, DNSSEC adoption remains patchy, 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.

   Attribute certificates are another potential solution, as a dCDN
   might be able to present a certificate containing a cryptographic
   assertion that it is an authorized delegate of the uCDN.  However,
   attribute certificate adoption among browser vendors does not make
   this a viable market adoption today.

Fieau & Oprescu          Expires January 7, 2016                [Page 5]
Internet-Draft          HTTPS delivery delegation              July 2015

   It is also possible that a uCDN could give its private credentials to
   one or more dCDNs.  Some virtual hosting providers in the application
   space have previously required this sort of credential sharing.
   However, this is usually very undesirable for the assignee of the
   credentials, and especially if they must share them with multiple
   parties, it significantly degrades the security of the entire
   architecture.

   Consequently, DNS redirection introduces a serious of difficulties
   that are more tractable at the application layer.  Barring any
   progress in the market adoption of other solutions described above,
   HTTPS redirection should be preferred to DNS redirection.

8.  Acknowledgments

   The authors would like to thank Jon Peterson and Jan Seedorf for
   their help in putting this draft together.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [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.ietf-cdni-redirection]
              Niven-Jenkins, B. and R. Brandenburg, "Request Routing
              Redirection Interface for CDN Interconnection", draft-
              ietf-cdni-redirection-10 (work in progress), July 2015.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

Authors' Addresses

Fieau & Oprescu          Expires January 7, 2016                [Page 6]
Internet-Draft          HTTPS delivery delegation              July 2015

   Frederic Fieau (editor)
   Orange
   38-40 rue du General Leclerc
   Issy les Moulineaux  92130
   FR

   Email: frederic.fieau@orange.com

   Iuniana Oprescu
   Orange
   38-40 rue du General Leclerc
   Issy les Moulineaux  92130
   FR

   Email: iuniana.oprescu@orange.com

Fieau & Oprescu          Expires January 7, 2016                [Page 7]