On Mon, Jun 12, 2017 at 11:19 AM, Salz, Rich <rs...@akamai.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
