Re: [TLS] Closing on 0-RTT

["Salz, Rich" <[e-mail]>]

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

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