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

From: [email-masked]
Date: Mon, 03 Jul 2017 14:25:27 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS PRIVate Exchange of the IETF.

        Title           : Padding Policy for EDNS(0)
        Author          : Alexander Mayrhofer
	Filename        : draft-ietf-dprive-padding-policy-01.txt
	Pages           : 7
	Date            : 2017-07-03

Abstract:
   RFC 7830 specifies the EDNS0 'Padding' option, but does not specify
   the length of padding to be used in specific applications.  This memo
   lists the possible options ("Padding Policies"), discusses the
   implications of each of these options, and provides a recommended
   option.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dprive-padding-policy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dprive-padding-policy-01
https://datatracker.ietf.org/doc/html/draft-ietf-dprive-padding-policy-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-padding-policy-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 3 Jul 2017 23:29:30 +0200

Hi,

i've updated the Padding Policy draft - the main change is the
inclusion of an actual recommendation, essentially a blunt copy of
Daniel's recommendations from his empirical research work.

I'm looking forward to hearing a discussion around these
recommendations - I will subsequently update the draft based on the
outcome of those discussions.

best,
Alex

On Mon, Jul 3, 2017 at 11:25 PM, <[email-masked]> wrote:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Hugo Connery <[email-masked]>
Date: Tue, 4 Jul 2017 10:40:02 +0200

Hi Alexander (and list),

Thanks, Alexander, for your efforts on the document
(and DKG for the empirical work).

May I suggest that another strategy is included, that of 
"always pad to the maximum message size".  This is obviously
wasteful, and may be recommended against.  However, I believe
its inclusion is equivalent to the "no padding" and "fixed
block size pad" options which are listed for completeness whilst
providing no or very little privacy protection.

The "always pad to maximum message size" option is actually 
the maximal privacy setting (when encrypted) but is horribly
wasteful.

Perhaps mention it directly after the "no padding option" and
describe that it provides maximal privacy protection, but is 
wasteful and more balanced strategies are described below,
including the recommended strategy.

Something like this:

---

4.2 Maximal Length Padding

In maximal length padding the sender pads every message to the
maximum allowed size for a message.

Advantages: Maximal length padding, when combined with encrypted
transport, provides the highest level of privacy protection.

Disadvantages: Maximal length padding places a heavy burden on all
parties, including the client, all intervening network equipment, and
the server.

Maximal length padding is not a recommended strategy.

---

Regards,  Hugo Connery

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 06 Jul 2017 18:09:51 -0700

> outcome of those discussions.

The new wording seems fine to me. I know we'll get people complaining 
about how long the suggested defaults are, but they are just suggested 
defaults, not demands.

--Paul Hoffman

---

From: Shane Kerr <[email-masked]>
Date: Fri, 7 Jul 2017 09:58:19 +0000

Hugo,

I'm curious what you mean by this. 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.

OTOH, people use Tor for browsing, so maybe someone will actually
want to do this? ;)

Seriously though, on the query side padding beyond a few hundred bytes
is not helpful, because no queries are longer than that. Maybe on the
response side it is indeed more privacy-protecting. 

Cheers,

--
Shane

At 2017-07-04 10:40:02 +0200

---

From: Shane Kerr <[email-masked]>
Date: Fri, 7 Jul 2017 10:05:06 +0000

Paul,

At 2017-07-06 18:09:51 -0700

> about how long the suggested defaults are, but they are just suggested 

I agree, and let me be the first to complain. ;)

As I said in my previous e-mail on this, I think we should minimize the
number of packets, so we should pad to a value that fits into something
based on the 1500 byte value.

The easiest approach is to use 500 bytes (not 468) as the block size.
Alternately we could use 486 bytes to account for tunneled traffic.
It's not a big concern, but I also don't see any reason not to do this.

Cheers,

--
Shane

---

From: Tony Finch <[email-masked]>
Date: Fri, 7 Jul 2017 11:20:22 +0100

Shane Kerr <[email-masked]> wrote:
> option to pad every query and response message to 65K bytes?

Reasonable values might be the MTU or the EDNS buffer size.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Southeast Fitzroy: Northerly or northeasterly, 4 or 5 increasing 6 at times.
Slight or moderate. Occasional rain. Good, occasionally poor.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 7 Jul 2017 14:48:13 +0300

> response side it is indeed more privacy-protecting. 

On query side, one could always pad to 286 (288 for TCP) bytes, AFAICT
the maximal query in practice is:

xx xx: Query length (TCP only).
xx xx: Query ID.
01: Query, requesting recursion.
00: DNSSEC errors are fatal.
00 01: 1 query
00 00: No answers
00 00: No authority
00 01: 1 additional record
<255 bytes>: QNAME
xx xx: QTYPE
00 01: QCLASS (1=IN).
00: Dummy domain (root)
00 29: OPT
04 B0: Maximum UDP response size (1200 bytes).
00 00 80 00: EDNS0, DNSSEC supported.
00 04: 4 bytes of EDNS data
00 12: Padding
00 00: 0 bytes of padding

However, responses are thornier issue. This is recursive, so it might
need to relay all kinds of responses. I could provke one ccTLD to
return a 3651 byte response with normal QTYPE (ZSK rollover plus
healthy amount of authoritative nameservers, most available over
IPv6). That kind of response when sent over UDP gets fragmented at
IP layer (not good) or triggers a fallback to TCP (not good).

-Ilari

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 19 Jul 2017 09:03:10 +0200

On Mon, Jul 03, 2017 at 02:25:27PM -0700,
 [email-masked] <[email-masked]> wrote 

> 	Filename        : draft-ietf-dprive-padding-policy-01.txt

I've read it. Summary:

1) This is very useful and important. Padding is not so easy as it may
seems and, without specific guidance, developers may do strange
things.

2) The document is OK and should be moved forward. Most TODO in the
text can be dropped, as well as the question mark at the end :-)

3) It is important for reviewers to note that it is based on actual
measurements (dkg at NDSS 17
<https://www.internetsociety.org/events/ndss-symposium/ndss-symposium-2017/dns-privacy-workshop-2017-programme>),
not just a theoretical analysis.

Editorial:

* section 3: ENDS should be EDNS

* section 4.2: "Therefore, this policy is equally useless "No Padding"
option described above" should be "Therefore, this policy is equally
useless AS THE "No Padding" option described above", no? (disclaimer:
I don't speak english)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 19 Jul 2017 09:16:24 +0200

On Fri, Jul 07, 2017 at 09:58:19AM +0000,
 Shane Kerr <[email-masked]> 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).