On Thu 2015-11-19 05:07:42 -0500, Warren Kumari wrote:
> I also think (but am not sure) that the sender should pad with random
> stuff[0] to prevent issues with "accidental" compression. Yes, we can
> say that compression MUST be disabled, but will all implementations
> follow this? The way many people write software is "look for something
> kind of similar on stackexchange and fiddle with it till it compiles".
> None of the easy examples I could find mention compression - e.g:
> http://stackoverflow.com/questions/5009271/any-good-examples-on-programming-using-libssl,
> https://wiki.openssl.org/index.php/Libcrypto_API, etc.
>
> I suspect I'm in the rough on this.
TLS stacks should be moving to having compression disabled by default --
on both server and client sides.
Packing the padding "random stuff" is likely to be interpreted as "fill
the space with output from your CSPRNG" which itself could cause
problems if your CSPRNG is flawed (e.g. the flawed dual_ec_drbg is more
vulnerable the more of its contiguous output is known).
And this still won't address any additional traffic leakage that could
happen as a result of compression still being enabled (e.g. CRIME-style
attacks where attackers get you to make queries that change the deflate
dictionary).
padding with randomness also fails at the "compatibility with some
potential future padding semantics" goal mentioned above.
--dkg
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
