On Sun, Oct 4, 2015 at 7:19 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
> On Sun, Oct 4, 2015 at 9:28 PM, Salz, Rich <rs...@akamai.com> wrote: > >> There are many lessons to be learned from this: that a bearer token > that is > >> repeated many times is not a good idea; that the trust model in the web > is > >> not great; but also that blindly compressing content with no regard to > its > >> structure and sources is dangerous and reveals information about the > >> cleartext. A security protocol should not do that. > > > > This is a great note, and excellent explanation. > > I'm not sure about some of it (I'm not trying to be argumentative). > > If compression leaks information from a structured message, then > surely an uncompressed message leaks the same information. No, not when they are encrypted. Consider the trivial case of ASCII text. Each character takes up the same amount of room, but if you compress (as an intuition pump, think of a simple Huffman code), then more common characters take up less room than less common characters. For a more complicated case, see: http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf -Ekr > As Kurt > eloquently put it, only the density of the information changed. > Naively, that means the encryption services are defective, and not > compression. > > Or maybe I should back pedal and ask: when is it safe to use TLS with > a structured message? Is it safe to use with HTTP? How about SMTP? If > HTTP always sends the cookie in the same position in unique messages, > then wouldn't that mean its not safe to use with HTTP over TLS? > > Perhaps I'm missing something obvious.... > > Jeff > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
