Olafur, At 2015-11-16 10:28:08 -0500 Olafur Gudmundsson <o...@ogud.com> wrote:
> > On Nov 16, 2015, at 8:41 AM, Andreas Gustafsson <g...@araneus.fi> wrote: > > > > Shane Kerr wrote: > >> Andreas Gustafsson <g...@araneus.fi> 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). > >> 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? 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. 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. Cheers, -- Shane _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
