Re: [dns-privacy] I-D Action: draft-ietf-dprive-padding-policy-01.txt

[Stephane Bortzmeyer <[e-mail]>]

On Fri, Jul 07, 2017 at 09:58:19AM +0000,
 Shane Kerr <[e-mail]> wrote 
 a message of 193 lines which said:

> Do you really mean to propose an option to pad every query and
> response message to 65K bytes? I guess I don't object it for the
> sake of completion, but it seems a bit crazy.

Note that there are already "crazy" policies mentioned in
draft-ietf-dprive-padding-policy-01 :-) ("No Padding" and "Fixed
Length Padding").

This proposal (improved by suggestions to pad queries at the maximum
size a query can be, and responses to the MTU or the EDNS buffer size)
is just a variant of the "Block Length Padding" policy, with a length
so large that in practice the padding will be always be the block
length and not a multiple of it.

Suggested text for the "Block Length Padding" section:

   In Block Length Padding, a sender pads each message so that its
   padded length is a multiple of a chosen block length.  This creates a
   greatly reduced variety of message lengths.  An implementor needs to
   consider that even the zero-length EDNS0 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, they have to be larger for
   the responses (see [dkg-padding-ndss] and section 5 for a
   discussion).

   It is also possible to have a very large block length, meaning that
   in practice the padding length will always be the block length. In
   that case, reasonable values may be 288 bytes for the query (the
   maximum size of a one-question query over TCP) and the EDNS buffer
   size of the server for the responses.
   
   Advantages: This policy is reasonably easy to implement, reduces the
   variety of message ("fingerprint") sizes significantly, and does not
   require a source of (pseudo) random numbers, since the amount of
   padding can be derived from the actual (unpadded) message.

   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 message can be predicted.  Therefore, the
   minimum and maximum length of the unpadded message is
   known. (Unless you use the variant with a very large block
   length but, in that case, the disadvantage is that you send a lot
   of "useless" bytes.)

   This is currently the recommended policy (see section 5).