On 12/2/15 4:45 PM, Watson Ladd wrote: > On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum <ja...@appelbaum.net> wrote: >> On 12/2/15, Eric Rescorla <e...@rtfm.com> wrote: >>> It's not really clear to me what the anti-traffic-analysis benefit of your >>> proposal >>> is over and above just padding everything to a fixed size. That's certainly >>> far >>> easier for the implementation to do, especially in typical stacks where the >>> application just calls SSL_Write (or whatever) and so there's no obvious >>> API point to provide the "next length", so as a practical matter the stack >>> will very often if not always be in "last block" mode. >>> >> >> I think that it eliminates all static distinguisher in the protocol >> for all data covered by the encryption. That is a fantastically >> wonderful benefit. > > What's a "static distinguisher"? Padding solves this problem as well, > but it also solves problems resulting from TCP segmentation down the > stack, which header encryption doesn't. What does header encryption > offer that padding does not?
Once again (for the n'th time in this thread): Padding is great and we should encourage implementations to do it, but it may be impractical to mandate (a) that *every* TLS 1.3 implementation use padding all the time, and (b) that *every* implementation that does use padding uses the *same* padded record size as every other TLS implementation. If TLS 1.3 did mandate that all implementations always pad to the same standard-defined record length (to echo Viktor Dukhovni, GO ATM! GO ATM! :) ), then it might be arguably the case that encrypting headers wouldn't add any further benefit. But short of that, encrypting TLS headers makes it strictly harder for a passive adversary - or an active adversary who can only inject but not block traffic - to distinguish between padded or unpadded TLS 1.3 streams, or to distinguish between TLS 1.3 streams padded to different block sizes. In particular, with encrypted records, we get a guarantee that nothing in the transmitted TCP stream content itself leaks information about the internal pattern of records, even if it's un-padded or differently padded from other streams. The attacker has to use other side-channels to perform such distinguishing attacks, and other side-channels are often lower-bandwidth (e.g., the total length of whole streams or bursts rather than individual records), and/or more noisy (e.g., the lengths and timings of TCP segments, which may get retimed and/or resegmented by all sorts of activities both at the endpoints and in the network). B > > Sincerely, > Watson >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
