On 16-Nov-2015 08:11 am, Bob Harold <[email protected]> wrote: > > On Mon, Nov 16, 2015 at 10:31 AM, Watson Ladd <[email protected] > <mailto:[email protected]>> wrote: > On Mon, Nov 16, 2015 at 10:28 AM, Olafur Gudmundsson <[email protected] > <mailto:[email protected]>> wrote: > > > >> On Nov 16, 2015, at 8:41 AM, Andreas Gustafsson <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Shane Kerr wrote: > >>> Andreas Gustafsson <[email protected] <mailto:[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 > > > > The reason they wanted 0-padding, and to be verified by the receiver is to > prevent that data from being used as a hidden communication channel by > viruses. Changing that to random, or not checked, is therefore a problem. > But then it is compressible, which is a different issue. I don't see an easy > solution.
There are a myriad of other, existing hidden communication channels, including 0x20 encoding, DGA, etc. I agree padding is another vector, but padding is only between the two DPRIVE entities, and is terminated there (unlike DGA which always hits the authoritative server). Padding is a steganographic channel and only useful when communicating directly with the peer that understands the meaning of the padding, in which case non-DNS packets could be sent to that peer, anyway. -d
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
