On Mon, Nov 16, 2015 at 10:28 AM, Olafur Gudmundsson <[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 > >> >>> 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
This is a problem that is easily fixed: turn off compression. TLS 1.3 is eliminating compression for similar reasons. > > 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 > > Olafur > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
