Thanks for the quick and clear responses! So, and I emphasize "not a blocking comment", it sounds like this isn't an RFC 2119 requirement for interoperability, but just good advice?
If so, this is more like "There is no specific requirement for the value of PADDING bytes, and receivers MUST accept any value. For example, implementers might set PADDING to 0x00 to prevent uninitialized memory leaks, or might choose a nonzero value to prevent predictable compression that would allow traffic analysis of padded packets." But your responsible AD will do the right thing. Spencer On Mar 1, 2016 05:21, "Tim Wicinski" <[email protected]> wrote: > > > Shane's explanation on padding is a great summary of the mailing list discussion during the document review. > > tim > (as DocumentShepherd) > > > On 3/1/16 5:39 AM, Shane Kerr wrote: >> >> 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
