This seems like content for the unified TLS/DTLS profiles draft that Sara, Tiru and DKG are now working on.
Sent from my iPhone > On Nov 20, 2015, at 12:00, Visweswaran, Gowri <[email protected]> > wrote: > > The below issue should apply to DTLS as well as TLS, i.e., we should that> > compression MUST be disabled for both DTLS and TLS implementations. > Does it make sense to add a section about this in the DNS over DTLS draft?> > Also, the wording in https://tools.ietf.org/html/rfc7525#section-3.3 (pasted > below) be changed from SHOULD to MUST and re-worded: > > 3.3. Compression > > In order to help prevent compression-related attacks (summarized in > Section 2.6 of [RFC7457]), implementations and deployments SHOULD > disable TLS-level compression (Section 6.2.2 of [RFC5246]), unless > the application protocol in question has been shown not to be open to > such attacks. > > 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 > _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
