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

I am bordering on "Yes" for this one.

(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.

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.

Thank you for addressing my DISCUSS

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.