On Fri, Jul 07, 2017 at 09:58:19AM +0000,
Shane Kerr <[email protected]> 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).
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
