Subject: [dns-privacy] Padding policies draft

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Jun 2017 12:16:00 +0200

draft-ietf-dprive-padding-policy is now expired. Anyone knows what
happens?

I think that the results presented by Daniel Kahn Gillmor at NDSS were
very promising (allowing to base policies on facts).

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 12 Jun 2017 11:38:56 +0000

Hi,

> draft-ietf-dprive-padding-policy is now expired. Anyone knows what

What happened is  that (obviously) i did not update the draft with the latest findings.
  
> very promising (allowing to base policies on facts).

I do agree, though i think the community should discuss the implications before we "set in stone" dkg's findings. Is the recommendation that he made also the view of the working group? Opinions?

best,
Alex

---

From: Shane Kerr <[email-masked]>
Date: Tue, 13 Jun 2017 07:37:40 +0000

Alexander and all,

tl;dr Lets move forward with our best guesses now. dkg's
      recommendations seem good, but maybe we can tweak these based on
      expected maximum packet sizes.

[ apologies for the rambling post ]

At 2017-06-12 11:38:56 +0000
Alexander Mayrhofer <[email-masked]> wrote:

> > I think that the results presented by Daniel Kahn Gillmor at NDSS
> > were very promising (allowing to base policies on facts).  
> 
> I do agree, though i think the community should discuss the
> implications before we "set in stone" dkg's findings. Is the
> recommendation that he made also the view of the working group?
> Opinions?

By NDSS I guess we mean this work?

https://gitlab.labs.nic.cz/labs/knot/merge_requests/692

I had not seen the presentation, and it was very interesting. I knew
that dkg was working on this, but didn't know he had actually put it
together. Nice to see actual measurements and modeling based on the
measurements!

One implicit assumption in this though is that bandwidth costs are
important to minimize.

My understanding is that DNS actually uses very little bandwidth
compared to actual traffic - which is reasonable since DNS is basically
metadata. While we see a lot of DoS or DDoS or reflection attacks that
consume a lot of bandwidth, mostly these are problems because DNS uses
UDP without validating source address; in DNS over TCP/TLS/DTLS/HTTP we
don't have that problem.

I am told that packets-per-second is the much bigger problem with DNS.
This makes sense because DNS is a horrible protocol for modern network
and server architectures in terms of performance, so we are almost
always CPU-bound.

For me this implies that we need to be very careful to avoid padding in
a way that adds extra packets. Note that we cannot insure this, because
there will always be some packets near the magical 1500 byte Ethernet
boundary, and we'll want to pad them, but those are rare even with
DNSSEC and encryption bloating things.

It also implies that padding which does NOT add extra packets might not
matter so much.

What we can say for sure is that we have no real idea how moving to
DNS-over-TLS is going to impact the performance of DNS going forward.
Does the CPU time for encrypting matter more than the CPU time for
doing DNS processing? Is it just a rounding error? Will the extra
handshakes for TLS be the highest cost? Will maintaining state about
clients on the server to minimize handshakes make memory our
bottleneck? 

Bringing us back to the question at hand... I think we should go ahead
and make recommendations based on the best guesses that we have now.
Those seem to be dkg's. Sure, it would be nice if we replicated the
work based on additional resolver data sets. I don't see many people
volunteering to do that work though. And sure, it would be nice if we
could have a handful of cryptanalysts able to publish their results 
think about the problem and make recommendations, but I don't see any
of them around either. :)

The only question I have is whether we want to expand the response
padding a little. I see a few options:

1. We could pad to 500 bytes, which would mean saving a packet for DNS
   messages between 1404 (468*3) and 1500 bytes long in the usual case.
2. We could pad to 486 bytes, which means that we would get as many
   paddings as possible in a 1460 byte packet (small enough for tunneled
   IPv6 traffic). This would save a packet for DNS messages between
   1404 and 1460 bytes.

I especially like that 486 is easily confused with 468, dkg's original
recommendation. ;)

A similar logic about packet sizes might be applied for query padding,
but in practice queries are never that big so I am happy with the 128
byte recommendation.

Cheers,

--
Shane

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 28 Jun 2017 11:01:07 +0100

> On 13 Jun 2017, at 08:37, Shane Kerr <[email-masked]> wrote:
> 
> Alexander and all,
> 

I agree, I think an update to the draft referencing dkg’s work is the best way to proceed. This seems a good topic for discussion in Prague. 

Sara.

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 28 Jun 2017 12:02:38 +0200

On 6/28/17 12:01 PM, Sara Dickinson wrote:
> 
>> On 13 Jun 2017, at 08:37, Shane Kerr <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Alexander and all,
>>
> I agree, I think an update to the draft referencing dkg’s work is the 
> best way to proceed. This seems a good topic for discussion in Prague.
> 

I agree this would be a great discussion topic in Prague.

tim

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 28 Jun 2017 10:34:33 +0000

> I agree this would be a great discussion topic in Prague.

I'll spin a revision of the document, hopefully tomorroy - i think the doc itself would require like 5 mins airtime, though the discussion could get longer. dkg, would you want to join for a 3-min rehearsal of the work you did for NDSS?

best,
Alex