Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[[e-mail] (Martin Rex)]

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