Subject: Re: [dns-privacy] Direction of draft-mayrhofer-edns0-padding

From: Sara Dickinson <[email-masked]>
Date: Wed, 5 Aug 2015 17:50:44 +0100

> On 29 Jul 2015, at 13:28, Alexander Mayrhofer <[email-masked]> wrote:
> 
> Hi,
> 
> I'm working through my notes from the DPRIVE session regarding the EDNS0 Padding option. My takeaway was as follows:
> 
> - Generally, this seems to be a reasonable idea

I support this draft and would like to see it move forward.

> On 29 Jul 2015, at 17:23, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
>>> - Besides the use to evade size-based message correlation, this could 
>>> also be useful in other cases, eg. "proof of work" for clients when 
>>> requesting larger packets (Peter K.)
>> 
>> This is possibly a bad idea. In the IPsecME WG, we have had an active 
>> work item on proof-of-work for clients to prevent DDoS, with lots of 
>> good discussion on how to do it, and we're probably going to only leave 
>> it as an Experimental document. In summary, adding proof-of-work hurts 
>> the group you care most about, namely clients on small machines.
> 
> I agree with Paul here that conflating padding with proof-of-work seems
> like a bad idea.  

+1

> On 29 Jul 2015, at 19:06, Stephen Farrell <[email-masked]> wrote:
> 
> On 29/07/15 19:00, Paul Hoffman wrote:
>> On 29 Jul 2015, at 10:48, Stephen Farrell wrote:
>> 
>> We are not defining an API, so there is no way for the application layer
>> to know what it is running under.
> 
> Eh? There may be some implementations like that but I'd be very
> surprised if, when dprive is done, most implementations don't have
> an is_doing_dprive() call they can make use of in application
> layer code.

I don’t see this as a problem either. There is already coupling between the transport and the content of the DNS message (TC=1) and other EDNS0 options are transport dependent (STARTTLS, edns-tcp-keepalive). 

> On 29 Jul 2015, at 15:12, Paul Hoffman <[email-masked]> wrote:
> 
>> But we don't actually have a centre of expertise about effective
>> padding so I can see why you suggest CFRG. Ideas as to how to try
>> foster/create such a thing would be welcome. Mostly I think the
>> hard part there will be to attract the few folks who know about
>> this topic and are willing to work on it openly.
> 
> Agree. However, we are not in a rush on this (we haven't even agreed on TLS / DTLS), so having the discussion about where to pad before we blindly start padding in DNS.

But…  we do have running DNS-over-TLS code that we could improve today with padding. We do have operators interested in deploying DNS-over-TLS services. I think a good way to gather data on padding is to implement this option, but possibly with the ‘use with caution’ caveat suggested. 

Sara.

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 5 Aug 2015 15:33:35 -0700

On Wednesday, August 5, 2015 9:51 AM, Sara Dickinson wrote:
> > I'm working through my notes from the DPRIVE session regarding the EDNS0
> Padding option. My takeaway was as follows:
> >

I too support this draft. I said in the WG that we may be better served with TLS-level padding, but I was convinced by two arguments. First, TLS level padding will be available at best with TLS 1.3, so we may have to wait some time. And then, there is the general argument that when the application can do padding, this is more efficient than a generic TLS solution. So, yes, that draft is useful.

-- Christian Huitema