The EDNS(0) Padding Option
draft-ietf-dprive-edns0-padding-03

[Ballot comment]
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?

[Ballot comment]

- 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"

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot discuss]
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?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dprive-edns0-padding-02.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the DNS EDNS0 Option Codes (OPT) subregistry of the Domain Name System (DNS) Parameters registry located at:

http://www.iana.org/assignments/dns-parameters/

Option Code: 12 for Padding (Status: Optional) has been registered. This registration will have its reference changed to [ RFC-to-be ].

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: tjw.ietf@gmail.com, draft-ietf-dprive-edns0-padding@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org, "Tim Wicinski" , terry.manderson@icann.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The EDNS(0) Padding Option) to Proposed Standard


The IESG has received a request from the DNS PRIVate Exchange WG (dprive)
to consider the following document:
- 'The EDNS(0) Padding Option'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-02-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies the EDNS(0) 'Padding' option, which allows
  DNS clients and servers to pad request and response messages by a
  variable number of octets.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dprive-edns0-padding/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dprive-edns0-padding/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Document Shepherd:  Tim Wicinski
Area Director:      Terry Manderson
Document Type:      Proposed Standard

This document specifies the EDNS(0) ’Padding’ option, which allows
DNS clients and servers to pad request and response messages by a
variable number of octets.

Since this is deploying a new EDNS(0) option, it is marked as Proposed Standard while it is deployed.

2. Review and Consensus

This document was brought to the working group and immediately found consensus.  The only process issue was that this was being handled by the DPRIVE working group, and not DNSOP.  It was quickly confirmed by the co-chairs and the area director of DNSOP that this document could be handled here, and there was plenty of DNS subject experts to provide expert reviews

This document had wide consensus, and there was little controversy in this.

3. Intellectual Property

There are no known IPR disclosures, and the authors have confirmed they know of none.

4. Other Points

There are no downward references.

Under IANA considerations, the EDNS option code '12' was assigned to this feature.

Checklist

This section is not meant to be submitted, but is here as a useful checklist of things the document shepherd is expected to have verified before publication is requested from the responsible Area Director. If the answers to any of these is "no", please explain the situation in the body of the writeup.

X Does the shepherd stand behind the document and think the document is ready for publication?

X Is the correct RFC type indicated in the title page header?

X Is the abstract both brief and sufficient, and does it stand alone as a brief summary?

X Is the intent of the document accurately and adequately explained in the introduction?

X Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?

X Has the shepherd performed automated checks -- idnits (see ​http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests? (In general, nits should be fixed before the document is sent to the IESG. If there are reasons that some remain (false positives, perhaps, or abnormal things that are necessary for this particular document), explain them.)

X Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?

X Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?

X Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?

X If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?

X If this is a "bis" document, have all of the errata been considered?

X IANA Considerations: