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

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

On 29 Jul 2015, at 6:55, Stephen Farrell wrote:

> On 29/07/15 14:41, Paul Hoffman wrote:
>> 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.
>
> With no hats, I disagree. Given that we don't yet know how
> to effectively pad at any layer, my belief is that we should
> define the basic mechanism at every layer so that when someone
> does figure it out, the protocol mechanics exist.

Interesting. I thought we had heard discussion of padding at both 
layers, and thus I thought people would by now have good ideas about 
which is better. Drat.

> The way I think about this is a) the most effective padding
> can be done in the application layer, but b) that may not be
> feasible so lower layer padding (esp in TLS) should also
> exist and on the 3rd hand - there may be a few cases where
> different protocols are multiplexed in such a way that one
> lower layer padding mechanism could help with both, but
> that'll be really rare.

The way I think about this is that the application layer doesn't know 
whether or not it is covered by TLS, so any padding done there when TLS 
is not used wastes bandwidth. TLS always knows that it is running, and 
what is running under it, and therefore padding is always appropriate 
there.

>> I think we need to get more
>> input (possibly from CFRG) about the benefits of padding at each 
>> layer.
>
> (With hat:-) CFRG is not the right group for a few reasons. First -
> effective use of padding like this isn't a crypto thing - we're not
> dealing with a block cipher here. CFRG are also busy enough right now
> on stuff they should be getting done.

Probably true.

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

--Paul Hoffman