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