Hi folks-- On Wed 2015-07-29 09:41:10 -0400, Paul Hoffman wrote: > On 29 Jul 2015, at 5:28, Alexander Mayrhofer wrote: >> 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.
In the TLS WG, the broad consensus is that if padding is possible at the application layer, that is the right place to pad. 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. >> - 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 agree with Paul here that conflating padding with proof-of-work seems like a bad idea. For one, proof-of-work schemes tend to encourage one partner to dictate the work to the other partner -- in such a scheme, each peer wouldn't be able to pad according to its known traffic patterns. for another, if the proof-of-work scheme is intended to require some kind of puzzle-solving, i wouldn't want someone who just wants to pad to have to incur extra computational costs. If someone wants a "proof-of-work" extension to DNS, i think that should be specified independently so that it doesn't get tied into this proposal. It's not like the registry [0] is short of codepoints. In practice, the EDNS0 spec appears to allow the use of unknown options for padding already, since peers are expected to ignore options they don't know. Adopting this draft would provide a codepoint allocation that explicitly acknowledges this as a practice and avoids codepoint squatting or abuse of the "Reserved for Local/Experimental Use" section for folks who try to make use of it. --dkg [0] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11 _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
