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. 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. > 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. 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. >> - 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. I also think separating out proof-of-work ideas is better. Cheers, S. > >> - 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 > > _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
