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

[Sara Dickinson <[e-mail]>]

> On 29 Jul 2015, at 13:28, Alexander Mayrhofer <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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.