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