> 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... _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
