Re: [TLS] Closing on 0-RTT

[Colm MacCárthaigh <[e-mail]>]

On Mon, Jun 12, 2017 at 11:19 AM, Salz, Rich <[e-mail]> wrote:

> > The one case here where I'd really argue for a "MUST" is middle-boxes
> like CDNs. The concern I have is if someone has an application that uses
> throttling or is vulnerable to a resource-exhaustion problem and goes and
> puts a CDN in front of it, it's not obvious that enabling TLS 1.3 could
> open them to a new kind of DOS attack.
>
> A CDN is not a middle box.  It *is* origin as far as the end-users are
> concerned, because of the business relationship between the CDN and the
> content provider.  Or, if you don't like that reasoning, then it's not a
> middlebox as the IETF uses the term.
>
> If the intermediary is vulnerable to the resource attacks, that's the
> intermediary's issue.
>

[ Browser ] <----> [ CDN ] <----> [ Origin ]

Sorry - I'm not trying to be inflammatory here, it's just a descriptive
term. All I mean is that the CDN is a box in the middle, as in that
diagram.  Here's what I imagine:

* Operator A operates the origin, and they incorporate throttling as a
routine security feature.
* Operator B operates the CDN, and they offer TLS 1.3 as a feature, without
replay protection.
* Customer enables TLS 1.3 on the CDN, because they want the speed benefit.
Seems totally reasonable!
* If the CDN caches the requests, then the customer is now vulnerable to a
new cache-analysis vulnerability.
* If the CDN doesn't cache the requests, then the customer is now
vulnerable to a new DOS vulnerability, in that the origin can be tipped
over or locked out via the throttling.

In this setup I say middle-box because the CDN is proxying requests. The
latter problem here is created for the origin; but by the CDN. It's a real
awful externality; because the CDN has a lot of incentive not to invest in
real replay protection and hand-wave the issue away. That's my real core
interoperability concern.

> We've already seen CDNs enable TLS 1.3 with unintentionally broken 0-RTT
> mitigations, so that's clear evidence that the existing guidance isn't
> sufficient. I think it would help manage the interoperability risks if we
> can point out to their customers that the configuration is unambiguously
> broken. Or at least, it helps to flag it as a security issue, which makes
> it more likely to get fixed. Absent this, the operators of "backend"
> applications would have to live with risk that is created by the upstream
> CDN providers for their own convenience. That seems like a really bad
> interoperability set up.
>
> I agree with this.  Which is why I prefer separate streams for early data,
> and some kind of signaling to the content provider that is clear and
> unambiguous.  I don't know how to do that when, say, the intermediary/CDN
> has a persistent connection to the backend...
>

That doesn't seem to be what some have deployed in the experimental
deployments. There seems to be remarkably little traction for the separate
streams.

-- 
Colm