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

["Peterson, Jon" <[e-mail]>]

Of course it depends on what angle you look at the problem from, but if there's no problem with HTTPS redirection (302 over TLS from uCDN to dCDN), and no problem with DNS redirection with DNSSEC, but there is a problem when you do DNS redirection without DNSSEC, I would ordinarily locate the problem there.

The insecurity of redirecting with the DNS (in the absence of DNSSEC) is moreover a problem much bigger than CDNs. There was a draft a few years ago called the "HARD problem" draft, where "HARD" stood for "high assurance re-direction" that looked at this as a general problem involving applications beyond HTTP like XMPP, and noting that it happened for resource records like SRV beyond CNAME. It has been a known issue for a variety of virtual hosting architectures, which have properties similar to CDN interconnection, for some time. I have a tough time understanding why we wouldn't want to acknowledge it as the problem here.  Saying the problem is the difficulty in getting keys to establish a TLS connection is to me sort of like saying the problem with being tied to a stone at the bottom of a lake is that you don't have a scuba tank.

But really, this was an offhand remark at a mic. If no else cares, do what you'd like over my objections. I think the new proposed text is more helpful to implementers, but it is solution text rather than problem text, and does not differentiate the situation for HTTPS and insecure DNS, so it doesn't address my concern.

Jon Peterson
Neustar, Inc.

From: Ben Niven-Jenkins <[e-mail]<mailto:[e-mail]>>
Date: Friday, October 16, 2015 at 10:40 AM
To: Jon Peterson <[e-mail]<mailto:[e-mail]>>
Cc: "Francois Le Faucheur (flefauch)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection

Hi Jon,

On 16 Oct 2015, at 17:06, Peterson, Jon <[e-mail]<mailto:[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/
===END===

Ben


Jon Peterson
Neustar, Inc.