Re Stephen's comment: In the choice between zero and random padding I'm almost entirely in the "meh, just pick one and move on" camp, but if forced to would side with putting in random crap and not zeros. I do think requiring checking of zeros on the receiver would be wrong.
Rather than picking either zero or random, should we allow support for both alternatives? Gowri -----Original Message----- From: dns-privacy [mailto:[email protected]] On Behalf Of Stephen Farrell Sent: Thursday, November 19, 2015 2:16 PM To: Daniel Kahn Gillmor; Warren Kumari; Stephane Bortzmeyer Cc: Shane Kerr; Andreas Gustafsson; [email protected]; Alex Mayrhofer Subject: Re: [dns-privacy] Non-zero padding (was EDNS0 padding with non-0 MUST respond with FORMERR?) On 19/11/15 18:34, Daniel Kahn Gillmor wrote: > 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-progr >> amming-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. In the choice between zero and random padding I'm almost entirely in the "meh, just pick one and move on" camp, but if forced to would side with putting in random crap and not zeros. I do think requiring checking of zeros on the receiver would be wrong. S. > > --dkg > _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
