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

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

Hi Jon,

> On 16 Oct 2015, at 00:52, Peterson, Jon <[e-mail]> wrote:
> 
> 
> If I recall the substance of my comment was that the cdni-redirection
> mechanism works for HTTPS redirection a lot more securely than for DNS
> redirection, and that the particular problem with DNS redirection when
> using HTTPS (that you will end up seeing a surprising certificate on the
> other side of your TLS connection) should be noted since DNS redirection
> is in scope of cdni-redirection draft. I don't think the problem needs to
> be solved there, but it needs to be acknowledged. Because DNS responses
> are insecure (barring DNSSEC), then using DNS for redirection can
> introduce the problems discussed in draft-fieau-https-delivery-delegation.
> Dropping in a reference to that draft, or summarizing the problem, would
> suffice.

The challenge with writing a paragraph like that is that draft-fieau-https-delivery-delegation misunderstands how DNS works and the security issue it highlights doesn’t exist in practice.

From the slides for draft-fieau-https-delivery-delegation from the last IETF, Section 5 of draft-fieau-https-delivery-delegation states:

“””
   In this case, the DNS resolver,
   when it queries for the hostname associated with the uCDN URL, will
   be served a DNS response (such as CNAME) that will direct the client
   to the dCDN.  However, in an HTTPS environment, this will result in
   the client containing a domain other than the one originally
   specified by the URL inputted by the end user.  Consequently, this
   will almost certainly result in a security failure when the browser
   attempts to negotiate TLS with the web server it contacts, as the
   change in domain name will be indistinguishable from a malicious
   attacker.
“””

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). 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).

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.

HTH
Ben


> 
> I don't think the text below really captures that. If this is super
> confusing I can send text.
> 
> Jon Peterson
> Neustar, Inc.
> 
> On 10/15/15, 5:25 AM, "Francois Le Faucheur (flefauch)"
> <[e-mail]> wrote:
> 
>> Hi Jon,
>> 
>> We¹ll wait a couple more days to hear back from you on the point below,
>> and then move the document forward.
>> 
>> Thanks
>> 
>> Francois
>> 
>>> On 7 Oct 2015, at 14:04, Francois Le Faucheur (flefauch)
>>> <[e-mail]> wrote:
>>> 
>>> Jon,
>>> 
>>> Can you confirm this new rev addresses your comment appropriately?
>>> I believe the text that was added for that purpose is:
>>> ³
>>> 3.1.  Redirection of encrypted traffic
>>> 
>>>     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.
>>> ³
>>> 
>> 
> 
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni