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

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

>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. If
that is an operational requirement of the DNS redirection mechanism in
cdni-redirection, it needs to be made explicit. 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.

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.

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

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

Jon Peterson
Neustar, Inc.