Padding Policies for Extension Mechanisms for DNS (EDNS(0))
draft-ietf-dprive-padding-policy-06

[Ballot comment]
At risk of triggering suggestions that there is an echo in the room: This
document is targetting Experimental status.  Is there a way to know when
the experiment has ended and/or what the conclusion is?

I know this document does not claim to be exhaustive, but I wonder
if there was any consideration for a "random multiple fixed block length
padding", where a fixed block length is used, but the padded message does
not always use the smallest multiple of the block length that will fit the
message.  That is, sometimes there is an extra block length or three of
padding after the "normal" padding to get to the block length.  (This
strategy is quite closly related to Random Block Length Padding, where the
candidate block lengths are multiples of the single "fixed" block length,
but I cannot convince myself that the two are completely identical.)

Section 4.1

  The Block Size will interact with the MTU size.  Especially for
  length values that are a large fraction of the MTU, unless the block
  length is chosen so that a multiple just fits into the MTU, Block
  Padding may cause unneccessary fragmentation for UDP based delivery.
  Also, chosing a block length larger than the MTU of course always
  forces to always fragment.

This paragraph is (modulo two words) a duplication of a previous paragrpah
in this section; I think this one (the penultimate paragraph) should be
removed.

Section 7

  No matter how carefully a client selects their Padding policy, this
  effort can be jeopardized if the server chooses to apply an
  ineffective Padding policy to the corresponding response packets.
  Therefore, a client applying Padding may want to choose a DNS server
  which does apply at least an equally effective Padding policy on
  responses.

Is there any way for the client to determine the behavior of DNS servers in
this matter other than trial-and-error?  Perhaps some additional text would
be helpful.

  [...] Counter-measures
  against such other side channels could include injecting artificial
  "cover traffic" into the stream of DNS messages, or delaying DNS
  responses by a certain amount of jitter.  Such strategies are out of
  scope of this document.  Additionally, there is neither enough
  theoretic analysis nor experimental data available to recommend any
  such countermeasures.

(This seems very closly aligned with Eric's DISCUSS.)  My understanding is
that in general, random jitter is not actually very helpful in this regard.
So I'm curious to hear a summary of the WG discussions on this strategy.

[Ballot comment]
(I might ballot "yes" on a more mature version of this as standards track or BCP, should one be offered :-) )

Why is this experimental? What is the nature of the experiment? Even if it's just to get more operational experience, it's worth saying that explicitly.

§2: There are a number of lower-case versions of normative keywords. Please consider the boilerplate from RFC 8174.

§A.2: ' "Fixed Length Padding" MUST NOT be used except for experimental applications.'
This entire draft is experimental.

[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3169


I am marking this DISCUSS because it appears to endorse Random
padding, which is known to be an unsafe practice.

DETAIL
S 4.2.2.
>      Disadvantage: This policy requires a good source of (pseudo) random
>      numbers which can keep up with the required message rates.
>      Especially on busy servers, this may be a hindrance.
> 
>      According to the limited empirical data available, Random Length
>      Padding performs slightly worse than Block Length Padding.

Random padding allows an attacker who can observe a large number of
requests to infer the length of the original value by observing the
distribution of total lengths.

[Ballot comment]
S 4.1.
>      consider that even the zero-length EDNS(0) Padding Option increases
>      the length of the packet by 4 octets.
> 
>      Options: Block Length - values between 16 and 128 octets for the
>      queries seem reasonable, responses will require larger block sizes
>      (see [dkg-padding-ndss] and above for a discussion).

Above, you have SHOULD 128 which is very different from 16 bytes. Why
would I ever pad to 16 bytes?


S 4.1.
>      (see [dkg-padding-ndss] and above for a discussion).
> 
>      Very large block lengths will have confidentiality properties similar
>      to the "Maximal Length Padding" strategy (Section 4.2.1), since
>      almost all messages will fit into a single block.  In that case,
>      reasonable values may be 288 bytes for the query (the maximum size of

Reasonable values of what? "block size"? You say above that up to 128
is reasonable which implies that 288 is unreasonable


S 4.1.
> 
>      Disadvantage: Given an unpadded message and the block size of the
>      padding (which is assumed to be public knowledge once a server is
>      reachable), the size of a padded message can be predicted.
>      Therefore, minimum and maximum length of the unpadded message are
>      known.

Isn't maximum always known, because it has to fit within the message.


S 4.2.1.
>      the server.  Depending on the negotiated size, this strategy will
>      commonly exceed the MTU, and then result in a consistent number of
>      fragments reducing delivery probability when datagram based transport
>      (such as UDP) is used.
> 
>      Maximal Length Padding is NOT RECOMMENDED.

If this is "sensible:, why is it not recommended?


S 4.2.2.
>      Advantages: Theoretically, this policy should create a natural
>      "distribution" of message sizes.
> 
>      Disadvantage: This policy requires a good source of (pseudo) random
>      numbers which can keep up with the required message rates.
>      Especially on busy servers, this may be a hindrance.

This does not seem like a real issue. By assumption, you are operating
over TLS, in which case you have a secret which you can use to drive
your PRNG. That should be rather faster than running the crypto for
TLS.


S 4.2.3.
> 
>      Disadvantage: Requires more implementation effort compared to simple
>      Block Length Padding
> 
>      Random Block Length Padding (as other combinations of padding
>      strategies) requires further empirical study.

This does not seem like it is a good strategy. The only advantage
seems to be not requiring as much randomness, but as above, this is
not a real issue.

[Ballot comment]
Firstly, thank you for writing this, and also for addressing Joe Clarke's OpsDir notes (and, obviously, thanks to Joe for the review!).

I have a clarifying question and some nits:
Section 4.2.2:
" According to the limited empirical data available, Random Length Padding performs slightly worse than Block Length Padding."
Performs slightly worse along what axis? I'm assuming "the server can answer less queries per second", but could also be "uses more RAM", "higher CPU", "explodes randomly", etc.
I don't really think that this needs to be addressed, but if you are editing it anyway, and have an easy way to improve it...

Oh, Appendix A made me laugh :-)


Other than that, some nits:

1: Section 3.  General Guidance
"EDNS(0) options space: The maximum message length as dictated by protocol limitation limits the space for EDNS(0) options."
This flows a little oddly - perhaps "The maximum message length as dictated by the protocol limits the space..." (unless the "limitation limits" entertains you...)

2: Section  4.1:
"Note that the recommendation above applies only if DNS transport is encrypted."
I suggest "if the DNS transport..."

[Ballot comment]
I'm not sure why this document is experimental. It does not appear to me that it is important to use one common scheme everywhere and therefore just giving a recommendation in an informational doc seems appropriate. I guess with more experience the right next step would be to publish an BCP at some point.

The wording on MTU is rather weak in this document, given RFC7830 says:
"However, padded DNS messages MUST NOT exceed the number of
  octets specified in the Requestor's Payload Size field encoded in the
  RR Class Field (see Sections 6.2.3 and 6.2.4 of [RFC6891])."
Maybe be more explicit here.

Also the paragraph on MTU and fragmentation appears twice in this doc.

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

The IANA Services Operator has reviewed draft-ietf-dprive-padding-policy-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-04-04):

From: The IESG
To: IETF-Announce
CC: brian@innovationslab.net, draft-ietf-dprive-padding-policy@ietf.org, Brian Haberman , dprive-chairs@ietf.org, dns-privacy@ietf.org, terry.manderson@icann.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Padding Policy for EDNS(0)) to Experimental RFC


The IESG has received a request from the DNS PRIVate Exchange WG (dprive) to
consider the following document: - 'Padding Policy for EDNS(0)'
  as Experimental RFC

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 2018-04-04. 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


  RFC 7830 specifies the EDNS(0) 'Padding' option, but does not specify
  the actual padding length for specific applications.  This memo lists
  the possible options ("Padding Policies"), discusses implications of
  each of these options, and provides a recommended (experimental)
  option.




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

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


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

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

This document is requesting Experimental status. This status is appropriate
given that it describes several EDNS(0) padding strategies that may be
applicable for encrypted DNS traffic and extensive experimentation is needed
to determine which strategy is most applicable.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  RFC 7830 specifies the EDNS(0) 'Padding' option, but does not specify
  the actual padding length for specific applications.  This memo lists
  the possible options ("Padding Policies"), discusses implications of
  each of these options, and provides a recommended (experimental)
  option.

Working Group Summary:

The WG process for this document was smooth and well-supported. There
have been involved discussions, but the consensus for the final content
of this document is strong.

Document Quality:

The document is driven by empirical research carried out by Daniel K.
Gillmor to determine potential padding strategies for encrypted DNS
traffic. Several WG participants have indicated a desire to begin
experimentation with the recommended padding strategy.

Personnel:

Document Shepherd is Brian Haberman.
Responsible Area Director is Terry Manderson.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

The document shepherd reviewed all versions of the document as they were
published. The review focused on the clarity of the description of each
potential padding strategy and the completeness of the analysis of each
strategy.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

There were several in-depth reviews posted to the mailing list and the
document shepherd is happy with those reviews.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns from the document shepherd.

There are two pending edits that will be incorporated into the document
at the next revision:

1. Section 4.3 : "This policy requires a good source of (pseudo) which"
should be "This policy requires a good source of (pseudo) randomness
which"

2. Section 5 : "research performed by Daniel K.  Gillmor [dkg-padding-ndss]"
can be re-worded as "research described in [dkg-padding-ndss]"


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

This document represents a strong consensus within the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

N/A.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

One normative reference is to an external document published on an
external website (dns.cmrg.net).

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

N/A.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A.