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

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

I wouldn't say the problem is that malicious attack, so much as it is a resolver's inability to distinguish normal redirection from an attack. DNSSEC lets you distinguish those things - if you get redirected to another domain, with DNSSEC you have a cryptographic assurance that the target domain sent you there, and without DNSSEC, you don't know if you're being redirected by the target domain or an attacker. Because DNSSEC is not widely available in the environments under consideration (yet), in practice this means that to get security for these applications when you do DNS redirection you end up doing the sorts of workarounds that you detailed in your last mail, the sorts of workarounds people are now trying to improve as HTTPS becomes more prevalent through measures like Keyless SSL.

HTTPS redirection is different because the entity sending you the redirection (the 302) is sending it to you over TLS, when you've already established a security association and you have a cryptographic assurance that the redirection came from the target domain. An attacker who forges a DNS response to the original formation of that security association (as you try to dereference https://example.com) would simply result in that security association never being established. But in that case, you know it's an attack. That's what different - in the DNS you don't. So no, I think the situation is different for HTTPS redirection than for DNS redirection: in HTTPS redirection, it is clear when you receive the redirection response whether it came from an attacker or the target domain - you always know it was the target domain (to the degree you trust your crypto anyway).

Yes, where we disagree is that I think specifying DNS as a redirection method has different security properties than specifying HTTPS as a redirection method. Doesn't mean there aren't workarounds to address DNS's situation, but I think eliding or skimming over these differences does implementers and future specifications a disservice - we should explain what they are. Now, it's not my intention here to burden the cdni-redirection document with detailing a solution for secure DNS redirection in the absence of DNSSEC. My mic comment merely suggested that, since people were talking about how to improve the workarounds, that describing the problem here seemed appropriate.

Jon Peterson
Neustar, Inc.

From: Ben Niven-Jenkins <[e-mail]<mailto:[e-mail]>>
Date: Saturday, October 17, 2015 at 4:44 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

Jon,

On 17 Oct 2015, at 00:12, Peterson, Jon <[e-mail]<mailto:[e-mail]>> wrote:

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.

Ah, OK, I think I’m starting to understand now. If I have understood correctly, what you would like is for the redirection interface to acknowledge that without DNSSEC a malicious DNS resolver could return DNS responses (IP addresses/CNAMEs/whatever) that steer the User Agent to a malicious server. DNSSEC would prevent that because responses would need to be signed and a malicious DNS resolver would therefore not be able to return malicious responses as it would not be able to generate properly signed DNS responses.

Do I have that correct?

If that’s the concern we can definitely include some text in the document about it.

However, that concern applies to HTTP & HTTPS redirection as well. If a CDN is performing HTTP redirection and the URI it is redirecting to contains a host (instead of an IP address) then DNS responses to resolve that host could also be hijacked by a malicious DNS resolver.

In the case of encrypted traffic, regardless of whether DNS based or HTTPS based redirects are used, if DNSSEC is not used then the DNS response hijacking problem still exists, except that when a User Agent tries to connect to the malicious server in the DNS response, the malicious server will not be able to deliver content to the User Agent as the malicious server will not be able to establish a TLS session with the User Agent.

However as the malicious DNS resolver is still able to steer traffic to a malicious server via a malicious DNS response, DNS response hijacking could still be used to mount what is effectively a DoS attack against the CDN/Content Provider. This is because the User Agent won’t be able to receive the content that it wants because it is being told to retrieve it from a server that it can’t establish a TLS session to.

Therefore, my suggestion would be that we include some text saying that if DNSSEC is not used, then there is the possibility that domains used for redirection (whether that is DNS redirection, HTTP redirection or HTTPS redirection) could have their DNS responses hijacked and bad things could result. The type of number of bad things a malicious actor could do is much greater with HTTP traffic than with HTTPS traffic but for HTTPS traffic the number of bad things a malicious actor could achieve is not zero, but they are limited to DoS rather than injection of their own content.

If you agree with the above I can propose some text to describe the problem.

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.

I’d like to document the issues that affect CDNI redirection. The challenge for me in doing this is that I do not know what all those problems are and there has not been a clear description of the problem(s) to work off so I’m having to infer what they are (that comment is not aimed at you in particular, the two drafts on this topic do not provide a clear problem description IMO).

I also think there may be a mis-connect because I believe the problem you are trying to highlight applies to all redirection methods (DNS, HTTP & HTTPS), and you seem to think it only applies to DNS based redirection.

Once we have the problem agreed, I can propose text to describe it.

Ben


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.