On 11/03/2016 01:15 PM, Martin Rex wrote: > 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. > >
Sorry, but that doesn't directly follow. With visible content type, an observer can *trivially* tell apart the two flows you mentioned in your next message. With current stacks' (lack of) padding and timing obfuscation, the observer can still tell the flows apart ... but you have a chance of writing a stack that prevents the observer from doing so. I don't think that "goes from 'impossible' to 'you have to write code'" can be construed as exactly zero benefit. -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
