> On Nov 16, 2015, at 11:32 AM, Shane Kerr <[email protected]> wrote: > > Olafur, > > At 2015-11-16 10:28:08 -0500 > Olafur Gudmundsson <[email protected] <mailto:[email protected]>> wrote: > >>> On Nov 16, 2015, at 8:41 AM, Andreas Gustafsson <[email protected]> wrote: >>> >>> Shane Kerr wrote: >>>> Andreas Gustafsson <[email protected]> wrote: >>>>> >>>>> I'm also wondering if there might be scenarios where the messages are >>>>> compressed before encryption. If that is the case, padding with zeros >>>>> is of limited value because they will mostly compress away, and the >>>>> ability to send data of similar compressibility to actual payload >>>>> data, or data of unpredictable compressibility, would be useful. >>>> >>>> It's an interesting idea, but I think I'd like to see some solid >>>> research on this. We understand how to add 0 bytes; I don't personally >>>> understand the implications of generating "similarly compressible" data >>>> to prevent attackers from doing traffic analysis. >>>> >>>> My own feeling is that we should proceed with 0-padding, and perhaps >>>> consider alternate schemes later if there is good guidance in the area >>>> of non-empty padding. >>> >>> We can certainly proceed with *sending* 0-padding. All I'm asking is >>> for receivers not to reject messages with nonzero padding, so that if >>> alternate schemes are introduced in future senders, they can >>> interoperate with existing receivers. >> >> +1 All resolvers should ignore the contents padding > > SHOULD or MUST? > > If it is SHOULD, then it makes sense to document what to do if you > check the padding. > > Personally I am happy if we decide that padding MUST be ignored (which > was my original suggestion). >
MUST is fine, >>>> Surely academics have looked at this! Do you have pointers to some >>>> papers covering this approach? >>> >>> I'm afraid not. >> >> Shane, >> >> There is lots of work in this area, but it is trivial to reason about the >> issue from DNS perspective >> Goal: hide how long the query name is, to defeat traffic analysis. >> >> Padding of the same value in each byte can be compressed to almost nothing >> ==> same as having no padding, ==> failed to meet goal. >> TLS by default in many cases, compresses before transmission, ==> DNS >> padding option must defeat compression >> >> I think the WG should consider if the current text of saying use 0x00 is not >> good enough, >> there are 3 options, use: >> - 0x00 >> - cheap randomness >> - real randomness source >> >> I think the middle one is good enough, a simple seeded hash function i.e. >> HMAC is sufficient or /dev/urandom > > Probably a paragraph saying "turn off TLS compression" is a better > approach than trying to figure out how to defeat the compression? yes that is much better, > > I your analysis is slightly incorrect, because DNS packets are highly > compressible. For example each RR includes RTYPE, TTL, and so on, which > will be identical for the entire RRset. I wish DNS software just stopped doing compression and we could rip out lots of ugly slow code :-) > > So for 0x00 we end up with the padding being compressed out and > effectively pointless. > > For random data (cheap or real), we end up with the padding being not > compressed at all, compared to the actual data, which is highly > compressed. It complicates traffic analysis, but I have faith that the > big data guys at the NSA can still get some probabilistic pattern > matching working. ;) > > If we worry about compression, then shouldn't we add entries that > compress "similarly" to actual packet data? That seems hard, hence my > suggestion to simply remind people to turn TLS compression off. I agree lets just say TLS compression MUST be OFF Olafur > > Cheers, > > -- > Shane > > _______________________________________________ > dns-privacy mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dns-privacy > <https://www.ietf.org/mailman/listinfo/dns-privacy>
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
