The EDNS(0) Padding Option
RFC 7830

Note: This ballot was opened for revision 02 and is now closed.

(Alia Atlas) (was No Objection) Yes

(Ben Campbell) Yes

(Spencer Dawkins) Yes

Comment (2016-02-29 for -02)
No email
send info
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) Yes

Comment (2016-03-01 for -02)
No email
send info
- 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"

(Brian Haberman) Yes

(Terry Manderson) Yes

(Jari Arkko) No Objection

(Deborah Brungard) No Objection

(Benoît Claise) No Objection

Comment (2016-03-01 for -02)
No email
send info
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?

(Joel Jaeggli) (was Discuss) No Objection

Comment (2016-03-02 for -02)
No email
send info
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?

(Barry Leiba) No Objection

Alvaro Retana No Objection

(Martin Stiemerling) No Objection