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

[Ben Niven-Jenkins <[e-mail]>]

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 <[e-mail]> 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/ <https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/>