Ilari Liusvaara wrote: >>> >>> Hiding the types does have its benefits (and it is also used for >>> zero-overhead padding scheme). >> >> Nope, ZERO benefits. But it totally breaks the middleware >> _at_the_endpoints_! > > Also, things like this should have been discussed like year or two > ago. Right now it is too late for major changes like this without good > cryptographic justifications (which AFAICT don't exist).
They WERE brought up back then, and several times in between. But the TLSv1.3 proposal has still not been fixed so far. Ignorance does not make problems go away. Instead, it means that one will have to fix it later. Since then, I've seen exactly ZERO rationale why the cleartext contenttype, which has existed through SSLv3->TLSv1.2 would be a problem. With the removal of renegotiation from TLSv1.3, it is even less of a problem to keep the contenttype in the clear. The removal of visibility of ContentType in TLSv1.3 will be a complete non-starter for TLSv1.3 as a drop-in replacement to TLSv1.2 for certain software architectures (including a lot of stuff we've been shipping for the last 5 years), because it is actively being used to signal state of the communication channel to the application and to *NOT* break application architecture that relies on (new) application data remaining visible on network sockets as "network readable" events. https://www.ietf.org/mail-archive/web/tls/current/msg13085.html https://www.ietf.org/mail-archive/web/tls/current/msg13106.html A similar issue exists for the visibility of Alert ContentTypes for efficiently detecting client-side connection closure. This has been described here: https://www.ietf.org/mail-archive/web/tls/current/msg21123.html The IETF technical leadership is supposed to prevent backwards-incompatible changes to be adopted and standardized that provide *ZERO* benefit, but severely impair interop and consumption. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
