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

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

The problem is indeed that if our assumption fails, the UA will not be able to tell that the warning is a false negative, and thus redirection will show up as an attack and may not succeed (though we all know users love to click through warning dialogs, ideally we shouldn't give them the opportunity). I think the sentence you added this time is true - this document does not cover a case where a UA receives a false negative security warning when our assumption does fail - though I think that is already basically said above. I also might say "this document" rather than "the interface described in this document."

Looking at this, I would really rather have the "operational mechanisms" note be attached to where I originally put it; if it's in a separate paragraph, then it needs more context to explain that we mean the operational mechanisms needed to prevent the assumption from failing as described in the previous paragraph.

Jon Peterson
Neustar, Inc.

From: Kevin Ma J <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, December 9, 2015 at 1:38 PM
To: Jon Peterson <[e-mail]<mailto:[e-mail]>>, "Francois Le Faucheur (flefauch)" <[e-mail]<mailto:[e-mail]>>, Niven-Jenkins Ben <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection

I guess, is the problem that the UA can't tell, or that the redirect fails?  Probably both?  The text I suggested below is more about the latter, though it could certainly be tweeked to also address the former?

Sent from my iPhone

On Dec 9, 2015, at 4:30 PM, Kevin Ma J <[e-mail]<mailto:[e-mail]>> wrote:

Hi Jon,

  Got it.  No ignoring in the UA (the "nonetheless" threw me off); and this RI only supports situations where there are no warnings and no need to ignore anything?.

"
  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 (in the absence of DNSSEC) 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, 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 the RT will be able to successfully complete a TLS handshake with the User Agent; the interface described in this document does not cover situations where the User Agent receiving a false-negative security warning would causes legitimate redirection to fail.

  Note: Operational 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.  Further mechanisms to notify User Agents of trusted redirection is also outside the scope of this document.
"

thanx!

--  Kevin J. Ma

From: Peterson, Jon [mailto:[e-mail]]
Sent: Wednesday, December 09, 2015 3:53 PM
To: Kevin Ma J; Francois Le Faucheur (flefauch); Niven-Jenkins Ben
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection


No, we shouldn't ever say that a UA should ignore a security warning.

We are saying that this document assumes the UA will never have to ignore a warning because, in any network with a uCDN using HTTPS that does DNS-based redirection, the dCDN will have gotten the keys or whatever beforehand. The fact that if we didn't assume that, we'd incur these problems, is what I have been trying to get the text here to note. We've long had text that talks about the workaround without ever saying what it is working around. We shouldn't expect implementers to just know what they are expected work around, we need to tell them. That's what my text tried to do.

So I would remove that proposed addition saying it is okay to ignore security warnings (the UA will have no way of knowing their legitimacy, that is indeed the problem). The sentence you added to the very end about further mechanisms is fine, though.

Jon Peterson
Neustar, Inc.

From: Kevin Ma J <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, December 9, 2015 at 12:37 PM
To: Jon Peterson <[e-mail]<mailto:[e-mail]>>, "Francois Le Faucheur (flefauch)" <[e-mail]<mailto:[e-mail]>>, Niven-Jenkins Ben <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [CDNi] Jon's commet on draft-ietf-cdni-redirection

Hi Jon,

  Thanks for the review and the updated text!  So, the concern that you are highlighting is that the UA, if it (falsely) detects a security warning, is going to need to be able to ignore the warning and keep going?  Is that correct?  If so, maybe we should make that even more explicit.  I'll admit I did not recognize that subtlety from the previous discussions.  I would also suggest that that we break up that last sentence, and if the operational mechanisms should include a mechanism for telling the UA to ignore the error, we should make that explicit, e.g.:

"
  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 (in the absence of DNSSEC) 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, 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 the RT will nonetheless be able to successfully complete a TLS handshake with the User Agent; the User Agent would need to be able to ignore false-negative security warnings generated by the legitimate redirection.

  Note: Operational 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.  Further mechanisms to notify User Agents of trusted redirection notifications is also outside the scope of this document.
"

thanx!

--  Kevin J. Ma

From: Peterson, Jon [mailto:[e-mail]]
Sent: Wednesday, December 09, 2015 2:03 PM
To: Kevin Ma J; Francois Le Faucheur (flefauch); Niven-Jenkins Ben
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection


While all of this is fine text and sets the stage for what I argue needs to be said, it still doesn't acknowledge that when HTTPS is used, a legitimate DNS-based redirection will look like an attack to a UA unless we do these workarounds. Your second paragraph noted that "the Redirection Target needs to be able to successfully complete the TLS handshake" but it still does not say why you would even need to note that, which is what I've been asking for. I've tried to add a second sentence to it below, and I also modified the rest of the paragraph a bit.

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 (in the absence of DNSSEC) 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, 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 the RT will nonetheless be able to successfully complete a TLS handshake with the User Agent; operational 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.

Jon Peterson
Neustar, Inc.

From: CDNi <[e-mail]<mailto:[e-mail]>> on behalf of Kevin Ma J <[e-mail]<mailto:[e-mail]>>
Date: Friday, November 20, 2015 at 11:31 AM
To: "Francois Le Faucheur (flefauch)" <[e-mail]<mailto:[e-mail]>>, Niven-Jenkins Ben <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection

Hi All,

  I thought I'd propose the alternate text (below), and see if it meets everyone's needs?

thanx!

--  Kevin J. Ma

The Redirection Interface defined in this document is intended to support delegation of HTTP-based traffic, including TLS encrypted HTTPS traffic, via DNS or HTTP redirection.  The User Agent request to the uCDN may be made over HTTP, HTTPS, or DNS.  In the case of an HTTPS request from the User Agent, the TLS session provides authentication of the request router sending the response.  In this case, the user agent may be confident that the HTTP redirection over TLS is genuine. In the cases of HTTP (without TLS) or DNS redirection, there is no inherent authentication of the request router.  In these cases, forged responses could be inserted by an attacker to maliciously redirect the User Agent to an alternate Redirection Target.  In the case of DNS redirection, DNSSEC [ref] could be used to authenticate DNS responses, however, configuration of DNSSEC is outside the scope of this document.

In all three of the above cases, either HTTP or HTTPS could be used to connect to the Redirection Target.  If the Redirection Target URL uses HTTPS, the Redirection Target needs to be able to successfully complete the TLS handshake and 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.


From: CDNi [mailto:[e-mail]] On Behalf Of Francois Le Faucheur (flefauch)
Sent: Sunday, November 01, 2015 3:03 AM
To: Niven-Jenkins Ben
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection

Hi Ben,

Minor editorial suggestions:

The redirection interface defined in this document enables a uCDN to return to a User Agent a DNS response on behalf of a dCDN. If DNSSEC is deployed, a User Agent can authenticate the DNS responses it receives, enabling it to distinguish between genuine (redirection) responses and malicious (redirection) responses . 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 to which the User Agent connects needs to authenticate itself to the User Agent.

Cheers

Francois


On 27 Oct 2015, at 22:14, Ben Niven-Jenkins <[e-mail]<mailto:[e-mail]>> wrote:

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 <[e-mail]<mailto:[e-mail]>> wrote:

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/

_______________________________________________
CDNi mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cdni