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

Hi Kevin,

Your proposed text works for me & is better than my original text IMO. 

Ben

> On 20 Nov 2015, at 19:31, Kevin Ma J <kevin.j.ma@ericsson.com> wrote:
> 
> 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
> 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> 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> 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
> https://www.ietf.org/mailman/listinfo/cdni
>  