Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection

While all of this is fine text and sets the stage for what I argue needs to be said, it still doesn't acknowledge that when HTTPS is used, a legitimate DNS-based redirection will look like an attack to a UA unless we do these workarounds. Your second paragraph noted that "the Redirection Target needs to be able to successfully complete the TLS handshake" but it still does not say why you would even need to note that, which is what I've been asking for. I've tried to add a second sentence to it below, and I also modified the rest of the paragraph a bit.

In all three of the above cases, either HTTP or HTTPS could be used to connect to the Redirection Target. When HTTPS is used to connect to the uCDN, if the uCDN uses DNS redirection (in the absence of DNSSEC) to identify the RT to the User Agent, then the new target domain name may not match the domain in the URL dereferenced to reach the uCDN: without operational precautions, this can make a legitimate redirection look like a DNS-based attack to a User Agent and trigger false-negative security warnings. When DNS-based redirection with HTTPS is used, this specification assumes that the RT will nonetheless be able to successfully complete a TLS handshake with the User Agent; operational mechanisms to distribute the required information and/or configuration, such as private keys, to surrogates and request routers in dCDNs are outside the scope of this document.

Jon Peterson
Neustar, Inc.

From: CDNi <cdni-bounces@ietf.org<mailto:cdni-bounces@ietf.org>> on behalf of Kevin Ma J <kevin.j.ma@ericsson.com<mailto:kevin.j.ma@ericsson.com>>
Date: Friday, November 20, 2015 at 11:31 AM
To: "Francois Le Faucheur (flefauch)" <flefauch@cisco.com<mailto:flefauch@cisco.com>>, Niven-Jenkins Ben <ben@niven-jenkins.co.uk<mailto:ben@niven-jenkins.co.uk>>
Cc: "cdni@ietf.org<mailto:cdni@ietf.org>" <cdni@ietf.org<mailto:cdni@ietf.org>>
Subject: Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection

Hi All,

  I thought I'd propose the alternate text (below), and see if it meets everyone's needs?

thanx!

--  Kevin J. Ma

The Redirection Interface defined in this document is intended to support delegation of HTTP-based traffic, including TLS encrypted HTTPS traffic, via DNS or HTTP redirection.  The User Agent request to the uCDN may be made over HTTP, HTTPS, or DNS.  In the case of an HTTPS request from the User Agent, the TLS session provides authentication of the request router sending the response.  In this case, the user agent may be confident that the HTTP redirection over TLS is genuine. In the cases of HTTP (without TLS) or DNS redirection, there is no inherent authentication of the request router.  In these cases, forged responses could be inserted by an attacker to maliciously redirect the User Agent to an alternate Redirection Target.  In the case of DNS redirection, DNSSEC [ref] could be used to authenticate DNS responses, however, configuration of DNSSEC is outside the scope of this document.

In all three of the above cases, either HTTP or HTTPS could be used to connect to the Redirection Target.  If the Redirection Target URL uses HTTPS, the Redirection Target needs to be able to successfully complete the TLS handshake and perform encryption of the TLS channel.  Mechanisms to distribute the required information and/or configuration, such as private keys, to surrogates and request routers in dCDNs are outside the scope of this document.

From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch)
Sent: Sunday, November 01, 2015 3:03 AM
To: Niven-Jenkins Ben
Cc: cdni@ietf.org<mailto:cdni@ietf.org>
Subject: Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection

Hi Ben,

Minor editorial suggestions:

The redirection interface defined in this document enables a uCDN to return to a User Agent a DNS response on behalf of a dCDN. If DNSSEC is deployed, a User Agent can authenticate the DNS responses it receives, enabling it to distinguish between genuine (redirection) responses and malicious (redirection) responses . Without DNSSEC a User Agent is unable to detect a malicious DNS redirect.  HTTPS redirection provides an additional layer of authentication via TLS because in order for the TLS handshake to complete, the server to which the User Agent connects needs to authenticate itself to the User Agent.

Cheers

Francois

On 27 Oct 2015, at 22:14, Ben Niven-Jenkins <ben@niven-jenkins.co.uk<mailto:ben@niven-jenkins.co.uk>> wrote:

Hi Jon,

Would the following text address your comments, feel free to wordsmith it to your liking.

===
The redirection interface defined in this document enables a uCDN to return
a DNS response on behalf of a dCDN. If DNSSEC is deployed
User Agents can authenticate the DNS responses they receive, enabling them to distinguish between genuine responses (redirections) and malicious responses (redirections). Without DNSSEC a User Agent is unable to detect a malicious DNS redirect.  HTTPS redirection provides an additional layer of authentication via TLS because in order for the TLS handshake to complete, the server the User Agent connects to must authenticate itself to the User Agent.
===

Thanks
Ben

On 22 Oct 2015, at 08:56, Ben Niven-Jenkins <ben@niven-jenkins.co.uk<mailto:ben@niven-jenkins.co.uk>> wrote:

The Redirection Interface defined in this document might be used to redirect a request where the User Agent will subsequently attempt to establish a TLS session with the Redirection Target. In such a case, any surrogate or request router to which the User Agent is redirected needs to be able to successfully complete the TLS handshake and to perform encryption of the TLS channel.

The private key for the host in the RT is needed in order to successfully establish a TLS session. The most widespread mechanism currently used by (non-interconnected) CDNs is for the owner of the host in the RT sharing their private key with their CDN(s) of choice. In cases where the owner of the host is not willing to share their private key, other mechanisms that allow the owner to not share their private key are used, for example Keyless SSL [REF].

CDNI by definition implies that a Content Provider’s content will be delivered by CDNs other than the CDN with which the Content Provider has a direct business relationship. Therefore, while CDNI does not introduce any new technical requirements on dCDNs when establishing TLS sessions, Content Providers may be less willing to have their private key shared with dCDNs than they are with their chosen CDN(s) in a non-interconnected scenario.

Mechanisms to distribute the required information and/or configuration to surrogates and request routers in dCDNs to enable a dCDN to successfully complete TLS handshakes and to perform encryption of the TLS channel for a particular host, such as private keys or the URI/IP address of a key server, are outside the scope of this document.

[REF] https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/

_______________________________________________
CDNi mailing list
CDNi@ietf.org<mailto:CDNi@ietf.org>
https://www.ietf.org/mailman/listinfo/cdni