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

From: [email-masked]
Date: Tue, 24 Nov 2015 04:15:20 -0800

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

        Title           : The EDNS(0) Padding Option
        Author          : Alexander Mayrhofer
	Filename        : draft-ietf-dprive-edns0-padding-01.txt
	Pages           : 6
	Date            : 2015-11-24

Abstract:
   This document specifies the EDNS(0) 'Padding' option, which allows
   DNS clients and servers to pad request and response messages by a
   variable number of octets.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dprive-edns0-padding-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-edns0-padding-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: Alex Mayrhofer <[email-masked]>
Date: Tue, 24 Nov 2015 13:19:47 +0100

FYI,

I've submitted a new version of the EDNS0 padding draft. The only major 
change is that it does now allow for non-0x00 padding octets. I think 
this was the (rough) consensus of the respective WG list discussion.

Tim said we're "close to WGLC"... Are we there yet? ;)

Alex

---

From: Shane Kerr <[email-masked]>
Date: Tue, 24 Nov 2015 13:32:37 +0100

Alex,

At 2015-11-24 13:19:47 +0100

> Tim said we're "close to WGLC"... Are we there yet? ;)

This version looks pretty good to me. Thanks for enduring the slings
and arrows of the IETF DNS crowd! ;)

Cheers,

--
Shane

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 24 Nov 2015 11:51:45 -0500

> this was the (rough) consensus of the respective WG list discussion.

Thanks Alex!  a couple more comments...

-------

   The PADDING octets SHOULD be set to 0x00.  Application developers who
   are concerned about misguided lower layer compression MAY instead
   fill the PADDING octets with the output of a cryptographic random
   number generator.  Responders MUST NOT reject messages containing
   non-0x00 PADDING octets.

I'm thinking we could add a sentence just before the last one here
"Applications MUST NOT send uninitialized memory in the padding octets."
to try to stave off another heartbleed opportunity.

(not that it will stop wilfully bad programmers, but at least we'll be
able to say "I told you so")

-------

   Responders MUST pad DNS responses when the respective DNS query
   included the 'Padding' option, unless doing so would violate the
   maximum UDP payload size.

I'm not sure about this directive.  Without telling responders how much
to pad (e.g. by multiples of 512-octet blocks?  by powers of two?  by
some other statistical distribution?), this requirement doesn't provide
any additional metadata protection, and it's just an additional 4
octets on each packet.

I don't think this draft should try to tell implementers how much to pad
(i'd prefer to keep the draft simple and have it describe mechanism and
not policy), so i think this requirement is out of place.  I think it
could be dropped altogether.  But if it is not dropped, it should be
converted to a much weaker statement than this MUST.

Regards,

          --dkg

---

From: Kumar Ashutosh <[email-masked]>
Date: Tue, 24 Nov 2015 19:05:07 +0000

Nice, that we relaxed the former part!

-----Original Message-----
From: dns-privacy [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Tuesday, November 24, 2015 22:22
To: Alex Mayrhofer <[email-masked]>; [email-masked]
Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-edns0-padding-01.txt

On Tue 2015-11-24 07:19:47 -0500, Alex Mayrhofer wrote:

> I've submitted a new version of the EDNS0 padding draft. The only 
> major change is that it does now allow for non-0x00 padding octets. I 
> think this was the (rough) consensus of the respective WG list discussion.

-------

I'm thinking we could add a sentence just before the last one here "Applications MUST NOT send uninitialized memory in the padding octets."
to try to stave off another heartbleed opportunity.

(not that it will stop wilfully bad programmers, but at least we'll be able to say "I told you so")

-------

I'm not sure about this directive.  Without telling responders how much to pad (e.g. by multiples of 512-octet blocks?  by powers of two?  by some other statistical distribution?), this requirement doesn't provide any additional metadata protection, and it's just an additional 4 octets on each packet.

I don't think this draft should try to tell implementers how much to pad (i'd prefer to keep the draft simple and have it describe mechanism and not policy), so i think this requirement is out of place.  I think it could be dropped altogether.  But if it is not dropped, it should be converted to a much weaker statement than this MUST.

Regards,

          --dkg

_______________________________________________
dns-privacy mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fdns-privacy&data=01%7c01%7caskuma%40064d.mgd.microsoft.com%7cdb993d81a39e4fa05deb08d2f4ef9f26%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CBMNjqlpVA9SAhhHfhw6L5cj1fhnYApZAyhGVqWOSmw%3d

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 24 Nov 2015 10:51:27 -1000

On Tuesday, November 24, 2015 6:52 AM, Daniel Kahn Gillmor
> ... 

Please don't do that. The draft already provides the simple recommendation,
"just set it to zero," which is the path of least effort for lazy
programmers. In fact, the very lazy programmers will probably just not use
padding at all. So you are worried about the hypothetical programmers who
are too clever by half. But there are so many hypothetical things that such
hypothetical types could do wrong, you don't want to spend time enumerating
each and any of them. 

-- Christian Huitema

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Nov 2015 10:15:44 +1100

In message <[email-masked]>
, Kumar Ashutosh writes:
> I'm thinking we could add a sentence just before the last one here "Applicati
> ons MUST NOT send uninitialized memory in the padding octets."
> I'm not sure about this directive.  Without telling responders how much to pa
> d (e.g. by multiples of 512-octet blocks?  by powers of two?  by some other s
> tatistical distribution?), this requirement doesn't provide any additional me
> tadata protection, and it's just an additional 4 octets on each packet.
> 
> I don't think this draft should try to tell implementers how much to pad (i'd
>  prefer to keep the draft simple and have it describe mechanism and not polic
> y), so i think this requirement is out of place.  I think it could be dropped
>  altogether.  But if it is not dropped, it should be converted to a much weak
> er statement than this MUST.

Padding is there to make responses indistigishable from each other.
For UDP pad to the requested UDP message size.  For TCP pad to the
largest response size sent so far.

This gives you roughly less than or bigger than 512, 12xx, 14xx and
4096 depending upon whether the query is retried over TCP or not
and the requested EDNS UDP size.

> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org
> %2fmailman%2flistinfo%2fdns-privacy&data=01%7c01%7caskuma%40064d.mgd.microsof
> t.com%7cdb993d81a39e4fa05deb08d2f4ef9f26%7c72f988bf86f141af91ab2d7cd011db47%7
> c1&sdata=CBMNjqlpVA9SAhhHfhw6L5cj1fhnYApZAyhGVqWOSmw%3d
> 
> https://www.ietf.org/mailman/listinfo/dns-privacy
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andreas Gustafsson <[email-masked]>
Date: Wed, 25 Nov 2015 11:19:05 +0200

> number generator.  Responders MUST NOT reject messages containing

I don't think the draft should specifically suggest using the output
of a cryptographic random number generator as padding.

Earlier, I said "the ability to send data of similar compressibility
to actual payload data, or data of unpredictable compressibility,
would be useful".  RNG output is neither of similar compressibility as
the DNS message payload nor of unpredictable compressibility - its
compressibility is predictably close to zero.  If you pad with random
data to a fixed total size, compress, and encrypt, it is still
possible to tell small DNS messages from large ones - messages that
were originally small will now be large, and vice versa.

I think the choice of padding content should be left to the
implementation, like the choice of padding size already is.

Also, the text "Responders MUST NOT reject..." should apply to both
responders and requestors.

My suggested wording would be:

  The PADDING octets SHOULD be set to 0x00.  PADDING octets
  of any value MUST be accepted in messages received.
 
or, if you think it is necessary to include a rationale for allowing
non-zero values, I would suggest:

  The PADDING octets SHOULD be set to 0x00.  Other values MAY be used;
  for example, if there is a concern that the padded message could be
  subject to compression before encryption, the padding could be
  chosen to control the size of the compressed message.  PADDING
  octets of any value MUST be accepted in messages received.
 
-- 
Andreas Gustafsson, [email-masked]

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 25 Nov 2015 15:15:42 -0500

tl;dr: It's not this simple, and we should not try to use this draft to
specify padding policy.

below are some pointers about why it's not so simple.  If you want to
make a separate draft about padding policy, i'm happy to have that
discussion there, but please don't hold this mechanism draft up for the
sake of policy discussion.

> Padding is there to make responses indistigishable from each other.

Padding for the sake of defeating traffic analysis is also about making
queries indistinguishable from each other, and about making combinations
of queries and responses indistinguishable from each other.

> For UDP pad to the requested UDP message size. 

Traffic analysis countermeasures are only useful when the content is
encrypted.  so presumably when you say "For UDP pad..." you mean for
DNS-over-DTLS?  and "For TCP pad..." means for DNS-over-TLS?  TLS and
DTLS themselves have per-message overhead, which itself may vary
depending on the ciphersuites used.

> For TCP pad to the largest response size sent so far.

Is that the largest repsonse ever sent by the server so far?  or ever
sent by the server in the current TCP connection?  or ever sent to the
specific IP address?

> and the requested EDNS UDP size.

enumerating the bins and anonymity sets is useful, but this breakdown
seems like it's missing request/response pairings and other kinds of
info leakage.  I'd love to have a discussion about optimizing padding
policy for the sake of DNS privacy with this sort of explicit bin
enumeration and some attempts to categorize things with actual data from
actual DNS request patterns.

But discussion around this draft is not the place for it.

     --dkg

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 25 Nov 2015 10:51:50 -1000

> tl;dr: It's not this simple, and we should not try to use this draft to

+1.

The draft is short and simple. It specifies the option code, the option
syntax, the expected value, and the expected processing by receivers. We
should leave it at that and get it published.

The precise ways to use padding is indeed a profound rabbit hole. We can
debate whether DNS level padding is preferable to TLS padding per RFC 7685.
We can debate whether padding should be all zeroes, or random, or something
clever. We can debate whether the length of padding should be to the max MTU
size, to some logarithmic sliding scale, or to some random value. All of
these have been proposed, all of these make at least some sense, and many of
these will probably end up implemented. One thing is certain, we will not be
able to get a strong consensus on any particular solution, and we probably
will not be able to make a complete inventory in the option specifying
draft.

Nor should we. The draft as is will not block the clever things that
implementers can come up with in the future. It achieves its objectives: get
the option code reserved, and make sure that the option can be used without
creating interop issues. We should be happy with that.

-- Christian Huitema