Spencer, At 2016-02-29 20:38:34 -0800 "Spencer Dawkins" <[email protected]> wrote: > Thanks for producing this draft. I do have one question about this text: > > The PADDING octets SHOULD be set to 0x00. Other values MAY be used; > for example, in cases where there is a concern that the padded > message could be subject to compression before encryption. PADDING > octets of any value MUST be accepted in messages received. > > I'm not entirely sure I understand the point of "SHOULD be set to 0x00". > I'm not questioning the SHOULD (you explain why choosing another value > would be a good idea, thank you ), but I'm wondering why there's a > normative requirement at all. > > I was trying to guess, and one hypothesis was that if the padding is > consistently 0x00, it's less likely to provide a covert channel (or at > least you'd be more likely to notice packets using different padding), > but the security considerations section didn't mention that, so I'm still > lost. > > If there's a reason to zero the padding bytes in the uncompressed case, a > sentence of explanation might be useful.
There was a lot of discussion on the list about this very topic, actually. I'm not sure if it can be reduced to a sentence or two. IIRC, the idea is that we should recommend some value there to give guidance for implementors to avoid common mistakes (such as using uninitialized memory, which might contain left-over values). Someone did raise the possibility of having a covert channel, but it was recognized that there are so many places for putting covert data into DNS that this is not really a concern. For example, one could simply use any unregistered EDNS(0) option and stick data in there, or encode it into the QNAME, or put values in the query ID, or... Putting random data in the padding was considered, but it did not seem to add any real value beyond zero-padding. Cheers, -- Shane "not an editor on the draft" Kerr _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
