Re: [dns-privacy] ENDS0 Padding Profile: Rough first draft

[Daniel Kahn Gillmor <[e-mail]>]

Thanks for
https://tools.ietf.org/html/draft-mayrhofer-dprive-padding-profile-00,
Alex!

On Tue 2016-11-01 07:09:28 -0400, Hugo Connery wrote:
> The list of strategies looks great.  Perhaps you could mention
> the "pad the message to the maximum possible message length"
> explicitly as a sub-case of "Block Length Padding".

The draft does mention "the maximum message length as dictated by
protocol negotiations" in the "General Guidance" section, but doesn't
make it an explicit padding option, or spell out what it is.  if you're
going to talk about "maximum possible message length" then it becomes
necessary to think about that here.

Note that the limits are different depending on whether you're using UDP
(DTLS) or TCP (TLS), and that the UDP limit depends on the underlying
MTU, which servers might not know.  the length limit over TCP (TLS)
connections is arguably bounded by either the size of the DNS query (16
bits?) or the TLS record boundary (2^14 + 1024, see
https://tools.ietf.org/html/rfc5246#page-21).

It might be worthwhile to have some discussion about choosing packet
size of the (D)TLS cleartext vs. packet size of the TLS ciphertext,
since those can be different values.

In implementations i've done, it's often much easier to pad the
cleartext to a fixed size, and to ensure that the security
considerations of https://tools.ietf.org/html/rfc7830#section-6 are
followed and that TLS compression is *off*.

Bob Harold wrote:

> Yes, I hope that the final document specifies all options, including
> the bad ones, and provides clear descriptions about the trade-offs
> involved.

I'm not convinced that documenting all possible patterns, including the
bad ones is a great strategy for a standards-track document.  I'd much
rather this document pick a single strategy, endorse it clearly, and
maybe at most include a mention of a few other strategies and why those
strategies are not recommended.

We want to make things *easier* for implementers, not harder.

fwiw, i'm puzzled by the claim that "Random Length Padding [...] is (at
first glance) the best strategy".  At first glance, i am not necessarily
convinced of this -- i found "block length padding" to be the easiest
and most understandable strategy when implementing.

(I'm also not convinced that a well-seeded, efficient CSPRNG would be
any sort of noticable hindrance to a server doing DNS-over-TLS at
wirespeed, but it's simply not necessary for block-length padding)

One missing proposal is "power of two padding" -- pad up to the nearest
power of two, with some minimum.  For example, pad up to 128 octets, and
then pad to 256 octets, 512 octets, 1024 octets, etc.

What would be really great (not as a standards draft, but as a regular
study) would be to frame the problem as an adversarial analysis "game",
taking samples of real-world DNS traffic, and see what can be inferred
From each of these strategies.  That might help to quantify the
differences between the schemes.

            --dkg

PS you've got RFC 7803 where you mean RFC 7830