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
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
