In message <9f5434b785954ee4a8b472a169f29...@hkxpr3002mb0103.064d.mgd.msft.net> , Kumar Ashutosh writes: > Nice, that we relaxed the former part! > > -----Original Message----- > From: dns-privacy [mailto:[email protected]] On Behalf Of Daniel K > ahn Gillmor > Sent: Tuesday, November 24, 2015 22:22 > To: Alex Mayrhofer <[email protected]>; [email protected] > Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-edns0-padding-01.txt > > On Tue 2015-11-24 07:19:47 -0500, Alex Mayrhofer wrote: > > > I've submitted a new version of the EDNS0 padding draft. The only > > major change is that it does now allow for non-0x00 padding octets. I > > think this was the (rough) consensus of the respective WG list discussion. > > Thanks Alex! a couple more comments... > > ------- > > The PADDING octets SHOULD be set to 0x00. Application developers who > are concerned about misguided lower layer compression MAY instead > fill the PADDING octets with the output of a cryptographic random > number generator. Responders MUST NOT reject messages containing > non-0x00 PADDING octets. > > I'm thinking we could add a sentence just before the last one here "Applicati > ons MUST NOT send uninitialized memory in the padding octets." > to try to stave off another heartbleed opportunity. > > (not that it will stop wilfully bad programmers, but at least we'll be able t > o say "I told you so") > > ------- > > Responders MUST pad DNS responses when the respective DNS query > included the 'Padding' option, unless doing so would violate the > maximum UDP payload size. > > I'm not sure about this directive. Without telling responders how much to pa > d (e.g. by multiples of 512-octet blocks? by powers of two? by some other s > tatistical distribution?), this requirement doesn't provide any additional me > tadata protection, and it's just an additional 4 octets on each packet. > > I don't think this draft should try to tell implementers how much to pad (i'd > prefer to keep the draft simple and have it describe mechanism and not polic > y), so i think this requirement is out of place. I think it could be dropped > altogether. But if it is not dropped, it should be converted to a much weak > er statement than this MUST.
Padding is there to make responses indistigishable from each other. For UDP pad to the requested UDP message size. For TCP pad to the largest response size sent so far. This gives you roughly less than or bigger than 512, 12xx, 14xx and 4096 depending upon whether the query is retried over TCP or not and the requested EDNS UDP size. > Regards, > > --dkg > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org > %2fmailman%2flistinfo%2fdns-privacy&data=01%7c01%7caskuma%40064d.mgd.microsof > t.com%7cdb993d81a39e4fa05deb08d2f4ef9f26%7c72f988bf86f141af91ab2d7cd011db47%7 > c1&sdata=CBMNjqlpVA9SAhhHfhw6L5cj1fhnYApZAyhGVqWOSmw%3d > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
