Subject: [CDNi] Update of draft-ietf-cdni-redirection

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 7 Oct 2015 08:55:58 +0000

Hi all,

We've updated draft-ietf-cdni-redirection. This update addresses all open issues, including:

- Updated MIME types to be in line with draft-ietf-cdni-media-types
- Updated security section to be in line with other CDNI docs
- Included short discussion on redirection and TLS

Ray

On 07/10/15 10:52, "CDNi on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF.
>
>        Title           : Request Routing Redirection Interface for CDN Interconnection
>        Authors         : Ben Niven-Jenkins
>                          Ray van Brandenburg
>	Filename        : draft-ietf-cdni-redirection-12.txt
>	Pages           : 30
>	Date            : 2015-10-07
>
>Abstract:
>   The Request Routing Interface comprises of (1) the asynchronous
>   advertisement of footprint and capabilities by a downstream Content
>   Delivery Network (CDN) that allows an upstream CDN to decide whether
>   to redirect particular user requests to that downstream CDN; and (2)
>   the synchronous operation of an upstream CDN requesting whether a
>   downstream CDN is prepared to accept a user request and of a
>   downstream CDN responding with how to actually redirect the user
>   request.  This document describes an interface for the latter part,
>   i.e. the CDNI Request Routing Redirection interface.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-cdni-redirection-12
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-12
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>CDNi mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cdni
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 7 Oct 2015 12:04:18 +0000

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

Kevin,

Can you confirm that this new rev is fully in line with cdmi-media-type?

Once we have confirmation for these two points we can push the document to IESG review.

Thanks

Begin forwarded message:

From: "Brandenburg, R. (Ray) van" <[email-masked]<mailto:[email-masked]>>
Subject: [CDNi] Update of draft-ietf-cdni-redirection
Date: 7 October 2015 10:55:58 CEST
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Hi all,

Ray

On 07/10/15 10:52, "CDNi on behalf of [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Abstract:

_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 8 Oct 2015 03:09:05 +0000

Hi Francois/Ray,

  For each of the payload type parameters, the spec is supposed to define a purpose, interface, and encoding.  Just to be totally explicit, I've been adding small blurbs for each, e.g., subsection under 6.1:

        <section title="CDNI RI Redirection Request Payload Type">
          <t>Purpose: The purpose of this payload type is to distinguish RI request messages.</t>
          <t>Interface: RI</t>
          <t>Encoding: see <xref target="anchors for Sections 4.4.1 and 4.5.1"/></t>
        </section>
        <section title="CDNI RI Redirection Response Payload Type">
          <t>Purpose: The purpose of this payload type is to distinguish RI response messages.</t>
          <t>Interface: RI</t>
          <t>Encoding: see <xref target="anchors for Sections 4.4.2 and 4.5.2"/></t>
        </section>

  Might also want to add a note to the RFC Editor in section 6.1 to change RFCthis to the published RFC number.

thanx.

--  Kevin J. Ma

From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: Wednesday, October 07, 2015 8:04 AM
To: Peterson, Jon <[email-masked]> ([email-masked]); Kevin Ma J
Cc: [email-masked]; Brandenburg, R. (Ray) van
Subject: Fwd: [CDNi] Update of draft-ietf-cdni-redirection

Jon,

     document.
“

Kevin,

Thanks

Begin forwarded message:

Hi all,

Ray

Abstract:

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 8 Oct 2015 08:56:06 +0000

Thanks Kevin.

Ray, can you reflect that ?

On 8 Oct 2015, at 05:09, Kevin Ma J <[email-masked]<mailto:[email-masked]>> wrote:

Hi Francois/Ray,

thanx.

--  Kevin J. Ma

From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: Wednesday, October 07, 2015 8:04 AM
To: Peterson, Jon <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>); Kevin Ma J
Cc: [email-masked]<mailto:[email-masked]>; Brandenburg, R. (Ray) van
Subject: Fwd: [CDNi] Update of draft-ietf-cdni-redirection

Jon,

     document.
“

Kevin,

Thanks

Begin forwarded message:

Hi all,

Ray

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Fri, 9 Oct 2015 11:32:42 +0000

Thanks Kevin, for checking as well as providing the improved text!

I've just uploaded -13 that includes Kevin's proposed text.

Ray

From: "[email-masked]<mailto:[email-masked]>"
Date: Thursday 8 October 2015 at 10:56
To: "[email-masked]<mailto:[email-masked]>", Ray van Brandenburg
Cc: "[email-masked]<mailto:[email-masked]>"
Subject: Re: [CDNi] Update of draft-ietf-cdni-redirection

Thanks Kevin.

Hi Francois/Ray,

thanx.

--  Kevin J. Ma

Jon,

     document.
“

Kevin,

Thanks

Begin forwarded message:

Hi all,

Ray

Abstract:

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 15 Oct 2015 12:25:25 +0000

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) <[email-masked]> wrote:
> 
> Jon,
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 15 Oct 2015 23:52:05 +0000

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.

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)"
<[email-masked]> 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
>
>> ³
>> ³

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 16 Oct 2015 08:49:19 +0100

Hi Jon,

> On 16 Oct 2015, at 00:52, Peterson, Jon <[email-masked]> wrote:
> 
> 

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 16 Oct 2015 16:06:27 +0000

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 16 Oct 2015 18:40:22 +0100

Hi Jon,

> On 16 Oct 2015, at 17:06, Peterson, Jon <[email-masked]> wrote:
> 
> 
> 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
> 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

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.

> for DNS redirection than it is for HTTPS redirection.

> HTTPS redirection

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.

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

> 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/ <https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/>
===END===

Ben

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 16 Oct 2015 23:12:36 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 16, 2015 at 10:40 AM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>
Cc: "Francois Le Faucheur (flefauch)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection

Hi Jon,

On 16 Oct 2015, at 17:06, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:

If

The proposed text just

===OLD===

[REF] https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/
===END===

Ben

Jon Peterson
Neustar, Inc.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 17 Oct 2015 12:44:21 +0100

Jon,

> On 17 Oct 2015, at 00:12, Peterson, Jon <[email-masked]> wrote:
> 

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

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 <[email-masked] <mailto:[email-masked]>>
> To: Jon Peterson <[email-masked] <mailto:[email-masked]>>
> Cc: "Francois Le Faucheur (flefauch)" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On 16 Oct 2015, at 17:06, Peterson, Jon <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>

---

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 17 Oct 2015 18:09:19 +0000

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.

Date: Saturday, October 17, 2015 at 4:44 AM

Jon,

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

Do I have that correct?

Ben

Jon Peterson
Neustar, Inc.

Hi Jon,

If

The proposed text just

===OLD===

Ben

Jon Peterson
Neustar, Inc.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 22 Oct 2015 08:56:47 +0100

Hi Jon,

> On 17 Oct 2015, at 19:09, Peterson, Jon <[email-masked]> wrote:
> 

Thanks for the great explanation. I understand why you see DNS as different to HTTPS redirection now :-)

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

I agree. I can have a go at some text for the case of DNS redirection of HTTPS traffic you describe above. Should we also leave in the text we already have (or the modified version I proposed)? And is it worth us adding text on the attack I describe below or do you think as it applies to all DNS resolutions in general it’s outside the scope of the redirection draft?

Thanks
Ben

> 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.
> 
>> On 17 Oct 2015, at 00:12, Peterson, Jon <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: <[email-masked]>
Date: Mon, 26 Oct 2015 13:26:17 +0000

Dear Ben, Jon,

As far as HTTPS delegation in CDNI draft is concerned, I’ve updated some parts of the draft to better clarify the issues you mentioned.
To me, the following security requirements should be pointed out when dealing with HTTPS delegation:
- ensure the legitimacy of delegation: a uCDN has willfully designated the uCDN,
- ensure a “seamless” security when redirecting users from one CDN to another: e.g. no security warning on user’ side
- guarantee the confidentiality of CDNs configuration and topology information.

For information, here is the link to the second version of the draft:

https://www.ietf.org/internet-drafts/draft-fieau-https-delivery-delegation-01.txt
Of course a review would be necessary to go further.

Thank you,

Best regards,
Frederic

De : CDNi [mailto:[email-masked]] De la part de Ben Niven-Jenkins
Envoyé : jeudi 22 octobre 2015 09:57
À : Peterson, Jon
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection

Hi Jon,

On 17 Oct 2015, at 19:09, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:

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

Thanks
Ben

Jon Peterson
Neustar, Inc.

Jon,

Do I have that correct?

Ben

Jon Peterson
Neustar, Inc.

Hi Jon,

If

The proposed text just

===OLD===

Ben

Jon Peterson
Neustar, Inc.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 27 Oct 2015 13:14:19 +0000

Hi Jon,

Would the following text address your comments, feel free to wordsmith it to your liking.

===
The redirection interface defined in this document enables a uCDN to return a DNS response on behalf of a dCDN. If DNSSEC is deployed User Agents can authenticate the DNS responses they receive, enabling them to distinguish between genuine responses (redirections) and malicious responses (redirections). Without DNSSEC a User Agent is unable to detect a malicious DNS redirect.  HTTPS redirection provides an additional layer of authentication via TLS because in order for the TLS handshake to complete, the server the User Agent connects to must authenticate itself to the User Agent.
===

Thanks
Ben

> On 22 Oct 2015, at 08:56, Ben Niven-Jenkins <[email-masked]> wrote:
>