Salz, Rich wrote: >> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >> which has existed through SSLv3->TLSv1.2 would be a problem. > > Because it's kind of implied in the charter, about making as much private as > possible. > >> 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. > > One app's data is another adversary's oracle. > Or is it that "signals have no morals"?
If you look at TLS records exchanged between two peers, and in particular if you perform a TLS handshake with same server yourself and compare, you can easily (heuristically) determine which TLS records of the original stream are hanshake records, and which are application data records. So there is exactly ZERO benefit of concealing the ContentTypes. But this concealing reliably breaks existing application middleware at the endpoints, which needs to reliably & quickly tell the difference between handshake&alert records and application data, so that it can leave application data records in the network buffer, so that the socket readable event remains visible for the event-based application logic. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
