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

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

Hi Jon,

> On 16 Oct 2015, at 17:06, Peterson, Jon <[e-mail]> wrote:
> 
> 
>> How DNS redirection works is that the User Agent does a resolution for
>> foo.example and it gets a response for foo.example. The fact a CNAME is
>> present & resolved by the DNS resolver is invisible to the User Agent
>> (evidenced by the fact the URL bar in the browser doesn¹t change domain
>> name/hostname when DNS redirection is performed).
> 
> It is certainly invisible to the browser when every dCDN holds the private
> key of every uCDN that might redirect to it, as you stipulate below.

I explained how it is done in the majority of cases today. That isn’t the only solution, Keyless SSL is another for example.

> If
> that is an operational requirement of the DNS redirection mechanism in
> cdni-redirection, it needs to be made explicit.

It’s not an operational requirement IMO, the operational requirement is that the dCDN is able to successfully complete the TLS handshake and to perform encryption (and decryption) of the TLS channel.

> The proposed text just
> says that "any surrogate or request router to which the User Agent is
> redirected needs to be able to successfully complete the TLS handshake"
> etc., which could be read to imply that as a solution, but not if you
> don't understand what the problem is in the first place. I was asking that
> this acknowledge the problem, not specify a solution.

Good, that’s what we were trying to do, maybe the text we used needs some refinement to be better understandable to others but we worded it the way it is to explicitly avoid suggesting a solution.

> Moreover, the substance of my comment was that the problem is different
> for DNS redirection than it is for HTTPS redirection.

> HTTPS redirection
> shouldn't require every dCDN to have every uCDNs private keying material.
> The proposed text treats this like the two methods have the same
> properties.

I think it may depend what angle you view the problem from. From my angle of view the problem is that the dCDN needs to successfully complete the TLS handshake and to perform encryption of the TLS channel. What the dCDN needs in order to do that is the same in both cases: private keys, or some other mechanism such as Keyless SSL that will enable the dCDN to complete the handshake and encrypt/decrypt the traffic.

The fact that for a lot of HTTPS 302 redirection cases the dCDN will be redirecting to a hostname under the dCDN’s control (but that is not guaranteed) may make being able to successfully complete the TLS handshake and to perform encryption of the TLS channel easier for the dCDN but it doesn’t change the basic problem of what the dCDN needs in order to do its job. And for (at least some) cases where the 302 redirection is to a hostname not under control of the dCDN the properties are the same for both DNS & HTTPS 302 redirection.

>> Therefore as long as the IP address(es) in the DNS response presents the
>> correct certificate for foo.example and has the correct credentials (e.g.
>> Private key for foo.example) to complete the TLS handshake &
>> encrypt/decrypt traffic on that TLS session the User Agent will not
>> complain. This is how DNS-based HTTPS redirection is done in CDNs today
>> where typically a CSP will provide their certificate & private key to the
>> CDN so the CDN can terminate TLS sessions successfully on the CSP¹s
>> behalf. which means if HTTPS redirection is insecure for CDNI then HTTPS
>> redirection used by CDNs in the wild today (without CDNI) is also
>> insecure (which it isn¹t).
> 
> Identifying a known workaround does not mean there isn't a problem. That
> there is a workaround is proof there is a problem.

I’m not sure I’d call the way that the majority of CDN delivered HTTPS traffic is delivered a workaround myself (I only described the most common mechanism, there are others mechanisms that don’t rely on sharing the private key and which are used in the wild, e.g. Keyless SSL).

But that’s off-topic so let’s move on.

> 
>> IMO I think the real problem is a different thing that
>> draft-slovetskiy-cdni-https-delegation-approaches hints at without
>> stating explicitly. That is how far will a CSP trust delegating its
>> credentials (e.g. Private key) given that the consequences of leakage of
>> those credentials are very bad. There are possible solutions to avoid the
>> CSP having to distribute their credentials (e.g. Keyless SSL) but from
>> the perspective of the redirection draft they¹re out of scope IMO.
> 
> The fact that there are two drafts trying to improve the workaround does
> not convince me that the problem isn't worth noting.

The problem is worth noting, which is what we did, as noted above it seems our text needs more work.

It is also worth noting IMO that neither of the two drafts actually describe or mention the problem we are discussing but merely hint at it and then attribute the cause of it to the presence of a CNAME in the call flow, rather than the true cause which is lack of ability of the dCDN to successfully complete the TLS handshake.

Anyway, does this proposal get us closer to some text you’d be happy with?

===OLD===
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.  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.
===NEW===
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/>
===END===

Ben

> 
> Jon Peterson
> Neustar, Inc.
>