On Mon, Nov 16, 2015 at 10:31 AM, Watson Ladd <[email protected]> wrote:
> 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 > > 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. -- Bob Harold
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
