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

From: Hugo Connery <[email-masked]>
Date: Tue, 1 Nov 2016 12:09:28 +0100

Hi,

The document looks like a great start.  

You seem to be using 'strategy' (28 times) and 'profile' (8 times)
interchangeably. You may wish to prefer one over the other, or
clearly delineate the difference in meaning.

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

I am not recommending it, but it has the maximum "confidentiality"
property (all EDNS messages look identical -- random noise of the same
size). Thus, it probably deserves an explicit mention, in the same
way that "no padding" deserves a mention as it has the minimum
"confidentiality" property.

You spell length as lenght twice in the first paragraph of section 4.5

Regards,  Hugo Connery

On Mon, 2016-10-31 at 22:40 +0100, Alexander Mayrhofer wrote:
> Hi,
> 
> I've posted a first rough cut of a "Padding Profile" draft,
> describing strategies regarding EDNS0 padding size (which we
> specifically did *not* address in RFC 7830):
> 
> https://tools.ietf.org/html/draft-mayrhofer-dprive-padding-profile-00
> 
> It's more like a "strawman proposal" rather than a polished document
> in the current version, but i'm more than happy to talk about it in
> Seoul if we have time. See the full I-D announcement below.
> 
> best,
> Alex
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>         Title           : Padding Profiles for EDNS(0)
>         Author          : Alexander Mayrhofer
> 	Filename        : draft-mayrhofer-dprive-padding-profile-00.txt
> 	Pages           : 6
> 	Date            : 2016-10-31
> 
> Abstract:
>    RFC 7830 specifies the EDNS0 'Padding' option, but does not
> specify
>    the amount of padding to be used in specific applications.  This
> memo
>    lists the possible options ("Padding Profiles"), discusses the
>    implications of each of these options, and provides implementation
>    guidance.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-mayrhofer-dprive-padding-profi
> le/
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Bob Harold <[email-masked]>
Date: Tue, 1 Nov 2016 15:05:52 -0400

> > https://datatracker.ietf.org/doc/draft-mayrhofer-dprive-padding-profi
Good start.

4.4.  Random Length Padding
'Alternatively, pad a certain percentage of "remaining space"?'
-- This, like fixed length padding, is discoverable and thus of no help.
You should specifically recommend against this, in case someone else thinks
of it and does not realize the problem with it.

-- 
Bob Harold

---

From: Hugo Connery <[email-masked]>
Date: Tue, 1 Nov 2016 20:38:43 +0100

On Tue, 2016-11-01 at 15:05 -0400, Bob Harold wrote:
> > [snip]

I think we may have a terminology misunderstanding here.

Obviously, constantly appending a fixed length padding is of little
value.  Based upon known characteristics (which the watchers have 
in abundance) it would be easy to identify the size of the fixed
offset and thus you move to length based analysis which reduces us to
the no padding 'strategy'.

But this is not what I think is being proposed.  "pad a certain
percentage" should perhaps be "pad a (pseudo) random number generated
percentage of the remaining length".  It comes under the heading
"Random length padding" so I think this a valid interpretation.

> You should specifically recommend against this, in case someone else
> thinks of it and does not realize the problem with it.

Yes, I hope that the final document specifies all options, including
the bad ones, and provides clear descriptions about the trade-offs
involved.  Eg. No padding provides no confidentiality increase, and 
constant length (fixed) appending of padding is equivalently bad as 
the attacker will likely have historical data which will allow them
to rapidly discover the fixed offset, thus the fixed offset strategy
degenerates to the no padding strategy and is equivalently bad.

Regards,  Hugo

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 01 Nov 2016 16:35:43 -0400

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

> 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:

> 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

---

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 3 Nov 2016 08:23:00 +0100

Bob,

thanks for that comment, i do agree it's misleading. I didn't have time to
flesh out that thought, but what i meant is that one strategy could be to
pad with a *random* percentage of the remaining space (with a new random
percentage on each message, of course). "Fixed length" Random Length
padding with eg. an upper limit of 128 octects of padding would still
reveal the maximum original message length, while padding with a random
percentage of the remaining space would not.

I will update the draft in the next revision accordingly, if there's
interest in continuing it.

best,
Alex

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 03 Nov 2016 12:30:12 -0700

> interest in continuing it.

Given that the padding was pretty unspecific, I think moving this draft 
forwards would be a very good thing (and a very easy thing).

--Paul Hoffman