Padding Profiles for EDNS(0)

This section is a non-exhaustive list of strategies with regards to choosing the appropriate padding length.

In the "No Padding" strategy, the EDNS0 Padding option is not used, and the size of the final (actually, "non-padded") message obviously corresponds exactly to the size of the unpadded messages. Even though this "non-strategy" could seem out of choice in this list, it needs to be considered for cases when either of the parties (client or server) does not apply padding, while the other party does. Note that following this "strategy" is required if the message size of the unpadded message does not allow for the Padding option to be included (less than 4 octets message space left). Therefore, this "non-strategy" is listed here for the sake of completeness. Advantages: The only advantage of this approach is that this "strategy" requires no additional resources on client, server and network side. Disadvantages: The original size of the message remains unchanged, hence this approach adds no additional entropy TODO: Recommend that this strategy MUST NOT be used unless message size disallows the use of Padding.

In fixed length padding, a sender chooses to pad each message with a padding of constant length. Options: Actual length of padding Advantages: Since the padding is constant in length, this strategy is very easy to implement, and at least ensures that the message length diverges from the length of the original packet (even only by a fixed value) Disadvantage: Obviously, the amount of padding easily discoverable from a single decrypted message. When a public DNS server applies this strategy, the length of the padding hence must be assumed to be public knowledge. Therefore, this strategy is almost as bad as the "No Padding" strategy described above.

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 (Discuss!) octets seem reasonable Advantages: This strategy 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. TODO: Recommended strategy?

When using Random Length Padding, a sender pads each message with a random amount of padding. Due to the size of the EDNS0 Padding Option itself, each message size is hence increased by at least 4 octets. The upper limit for pading is the maximum message size. However, a client or server may choose to impose a lower maximum padding length. Alternatively, pad a certain percentage of "remaining space"? Options: Maximum (and eventually minimum) padding length. Advantages: This strategy should create the best "distribution" of message sizes Disadvantage: This strategy requires a good source of (pseudo) random numbers which keeps up with the required message rates. Especially on busy servers, this could be a significant hindrance. TODO: Recommendation - this is (at first glance) the best strategy, but requires significant effort

This strategy combines Block Length Padding with a random component. Specifically, a sender randomly chooses between a few block lenght'es and then applies Block Length Padding based on the chosen block length. The random selection of block lenght might even be reasonably based on a "weak" source of randomness, such as the transction ID of the message. Options: Number of size of the set of Block Lengths, source of "randomness" Advantages: Compared to Block Length Padding, this creates more variety in the resulting message sizes for a certain individual original message length. Also, compared to "Random Length Padding", it might not require a "full blown" random number source. Disadvantage: Requires more implementation effort compared to simple Block Length Padding TODO: Recommend over simple Block Length Padding?