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

["Paul Hoffman" <[e-mail]>]

On 29 Jul 2015, at 5:28, Alexander Mayrhofer 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

That may be too strong of an assessment. There were questions about 
whether the padding should be done in DNS or in TLS. My personal view is 
that if the two types of padding give similar benefits, it absolutely 
should be done in TLS for many reasons. I think we need to get more 
input (possibly from CFRG) about the benefits of padding at each layer.

> - 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.

> - However, the draft should only specify the option itself, and not 
> indulge into the various usage scenarios

That's exactly the place we are ending up in IPsecME, and it's not where 
we expected.

> - The EDNS0 assignment policy is Speficiation Required / Expert 
> Review, hence does not necessarily require an RFC
> - The preferred way forward is individual draft, AD-sponsored.
> - Discussion can continue on the DPRIVE list
>
> Regarding the actual contents of the draft, my takeaway was:
>
> - Is "1" the right minimum length for the option? Why not "0"?
> - Padding must obviously not exceed the announced EDNS0 packet size - 
> some words about that
> - No consideration is required whether or not a server may pad, 
> because clients are required to ignore unknown options anyways.
> - The Security considerations section needs more work.
>
> Is that in line with the perception of the WG members? Anything I 
> forgot to mention / consider?

See above. I propose that we not do this at all if it turns out to be 
better done in TLS so that we don't create an attractive nuisance. If 
CFRG says that it is better to do it in the inner protocol, then we 
should proceed, but with the narrow focus of preventing analysis of 
TLS-protected traffic, not for proof-of-work.

--Paul Hoffman