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

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

Colleagues,

I like Jon's text. We'll include & publish a new version. 

Ben

> On 10 Dec 2015, at 00:54, Kevin Ma J <[e-mail]> wrote:
> 
> Hi Jon,
>  
>   Fair enough.  I'm ok with the text below.  I'm torn between being more explicit about the issues and maybe adding a few SHOULDs/MUSTs, and coming up with the least controversial text; I agree with deferring the discussion to draft-fieau.
>  
> thanx!
>  
> --  Kevin J. Ma
>  
> From: Peterson, Jon [mailto:[e-mail]] 
> Sent: Wednesday, December 09, 2015 7:09 PM
> To: Kevin Ma J; Francois Le Faucheur (flefauch); Niven-Jenkins Ben
> Cc: [e-mail]
> Subject: Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection
>  
> No, we really cannot say in our specification text that we assume the UA will (or even should) continue despite the presence of security warnings - my email was just being snarky by pointing out that users in fact tend to do that, but that is a bad thing, and it is our job as spec authors to prevent them from being in that position. I think we're shifting the focus here too much to the warnings themselves and not to the problem that is causing the warnings. The problem causing the warnings is that in this HTTPS case, the DNS redirect insecurely directs you to another domain, and that HTTPS should fail when that happens, if the domain does not hold the keying material that the UA expects.
>  
> The proper, long-term way to actually fix this is either to use DNSSEC, or to give up DNS redirection entirely and just use HTTPS. In that case the UA securely learns that it should negotiate TLS with the RT's domain instead of the original domain. But we're not going to tell people they have to do that.
>  
> The immediate solution (i.e. workaround) is "operational mechanisms" that we assume here, but do not detail - that is, the uCDN giving away its private key to all relevant devices in all dCDNs that could conceivably be RTs. All of your partners/competitors can now impersonate you: enjoy! That is why this is just a workaround.
>  
> The mid-term way to address this is the problem space that draft-fieau is trying (I think, anyway) to shape.
>  
> Are we home yet? Here's some proposed edits:
>  
>   In all three of the above cases, either HTTP or HTTPS could be used to connect to the Redirection Target. When HTTPS is used to connect to the uCDN, if the uCDN uses DNS redirection to identify the RT to the User Agent, then the new target domain name may not match the domain in the URL dereferenced to reach the uCDN: without operational precautions, and in the absence of DNSSEC, this can make a legitimate redirection look like a DNS-based attack to a User Agent and trigger false-negative security warnings. When DNS-based redirection with HTTPS is used, this specification assumes that any RT can complete the necessary TLS handshake with the User Agent. Any operational mechanisms this requires, e.g., private key distribution to surrogates and request routers in dCDNs, are outside the scope of this document. Further mechanisms to notify User Agents of trusted redirection are also outside the scope of this document.
>  
> Jon Peterson
> Neustar, Inc.
>