13 ms·
>It genuinely doesn't matter that you think it'd be a great idea, not the tiniest bit, since it would see no adoption. The discussion around TLS 1.3 delays inc
by pedrocr 8y ago
>It genuinely doesn't matter that you think it'd be a great idea, not the tiniest bit, since it would see no adoption.
The discussion around TLS 1.3 delays included plenty of people that also thought middleboxes should not be enabled. If a standard that broke compatibility with them completely would be adopted is an open question.
>TLS 1.3 did not take this "backwards compatibility at all cost" approach you describe. On the contrary, it was engineered very carefully to work _around_ middleboxes. The protocol is untidy as a result, with extraneous compatibility fields, but the cryptography remains as intended.
The second part contradicts the first. The standard has had to be made more complex to allow for the backwards compatibility and that's a future liability. We've had other holes in TLS from these extra complexities that are completely unneeded.
>Again, this issue you're reading about today is NOT a problem with TLS 1.3
Again that's not my point at all. I'm not discussing today's issue in particular. I'm referring to the fact that we keep finding bugs in TLS consistently. I was wondering if we were at the point were a clean slate would reduce this. I've made that point, someone else has pointed out to an experiment in doing just that, maybe someday we'll get a full test. You're dismissal of the actual question as if it's invalid is just being unpleasant without being helpful.