The EDNS(0) Padding Option
draft-ietf-dprive-edns0-padding-03
Yes
(Alia Atlas)
(Ben Campbell)
(Brian Haberman)
(Terry Manderson)
No Objection
(Alvaro Retana)
(Barry Leiba)
(Deborah Brungard)
(Jari Arkko)
(Martin Stiemerling)
Note: This ballot was opened for revision 02 and is now closed.
Alia Atlas Former IESG member
(was No Objection)
Yes
Yes
(for -02)
Unknown
Ben Campbell Former IESG member
Yes
Yes
(for -02)
Unknown
Brian Haberman Former IESG member
Yes
Yes
(for -02)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(2016-02-29 for -02)
Unknown
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.
Stephen Farrell Former IESG member
Yes
Yes
(2016-03-01 for -02)
Unknown
- intro: "significantly hampering" is over-stated, even though you do limit that to size-based correlation as a form of traffic analysis. This is a basic mechanism (a fine thing) but by itself does not counter traffic analysis that much. See e.g. [1] for a relevant study. Referencing [1] and/or [2] and saying that this mechanism isn't itself enough would be a good improvement. ([2] is a colleague's work btw, but I think is good:-). Neither [1] nor [2] are DNS-specific, not sure if there are publications that cover that. Without such a caveat, people might over-claim and not do the right things. Happy to help craft words for that if you want. [1] http://kpdyer.com/publications/oakland2012-peekaboo.pdf [2] http://arxiv.org/pdf/1410.2087v2.pdf - typo: "meta data of could still"
Terry Manderson Former IESG member
Yes
Yes
(for -02)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -02)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -02)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2016-03-01 for -02)
Unknown
Looking at this logic ... Responders MUST pad DNS responses when the respective DNS query included the 'Padding' option, unless doing so would violate the maximum UDP payload size. Responders MAY pad DNS responses when the respective DNS query indicated EDNS(0) support of the Requestor. Responders MUST NOT pad DNS responses when the respective DNS query did not indicate EDNS(0). ... I believe we need to improve the second paragraph. Taken out of context of the first paragraph, it might be misleading. Responders MAY pad DNS responses when the respective DNS query indicated EDNS(0) support of the Requestor and the 'Padding' option is not included. Editorial: However, even if both DNS query and response messages were encrypted, meta data of could still be used to correlate such messages with well known unencrypted messages, hence jeopardizing some of the confidentiality gained by encryption. One such property is the message size. meta data of?
Deborah Brungard Former IESG member
No Objection
No Objection
(for -02)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -02)
Unknown
Joel Jaeggli Former IESG member
(was Discuss)
No Objection
No Objection
(2016-03-02 for -02)
Unknown
changing my discuss to a comment since terry and the authors have a way forward that I am happy with and which I trust them to pursue. was - This is just something I want to discuss, it's not an objection... At this point we say: Implementations therefore SHOULD avoid using this option if the DNS transport is not encrypted. If you did allow this on unencrypted dns transport this seems like it serves as a utility function for DNS amplification. Wouldn't it be better to say MUST NOT? e.g. this is exclusively for use with TLS / DTLS supporting sessions?
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -02)
Unknown