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

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

On 29 Jul 2015, at 9:23, Daniel Kahn Gillmor wrote:

> In the TLS WG, the broad consensus is that if padding is possible at 
> the
> application layer, that is the right place to pad.

That will teach me to stop going to the TLS WG. :-)

> The rationale
> concerns countermeasures to traffic analysis -- in particular, the
> application layer has much more knowledge than the TLS layer about 
> what
> its traffic generally looks like.  traffic analysis countermeasures 
> are
> subtle and closely tied to existing patterns of usage.  TLS is an
> abstraction that is intentionally removed from what the application
> layer does.
>
> Also, there is no padding mechanism available in TLS at the moment :)
> i'm trying to get one into TLS 1.3 for those application layers that
> have nowhere to pad, and i could conceivably write up an extension to
> TLS 1.2.  But even having that mechanism, you'd need to be able to set
> policy about when to pad and by how much.
>
> So from the thinking and work i've done on this, padding at the
> application layer is preferable where possible.  Paul, you say you 
> have
> many reasons for wanting to do it in TLS -- can you explain some of
> those a bit more?  I want to make sure i'm not missing anything vital.

Basically, the DNS stack will not know whether or not it is running 
under TLS/DTLS when the query and reply are formed; TLS/DTLS will be 
opportunistic. So, to be safe, the DNS client or server will be forced 
to add padding even when it is not needed, and thus make every message 
longer.

We don't know how much padding is required to prevent analysis for 
particular query/response pairs, and thus need to add lots of 
random-length padding to each message to prevent the analysis. This 
seems wasteful. Instead, if the TLS stack could add the padding, it 
would only happen when needed.

But I understand the problem of "we don't even have that now" and "we 
don't know when we will have it". The draft in question is trivial to 
implement, but configuring it (with the length per query or response) 
seems impossible without adding large amounts.

--Paul Hoffman