> On 29 Jul 2015, at 13:28, Alexander Mayrhofer <alexander.mayrho...@nic.at> > 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
I support this draft and would like to see it move forward. > On 29 Jul 2015, at 17:23, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > >>> - 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. +1 > On 29 Jul 2015, at 19:06, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > On 29/07/15 19:00, Paul Hoffman wrote: >> On 29 Jul 2015, at 10:48, Stephen Farrell wrote: >> >> We are not defining an API, so there is no way for the application layer >> to know what it is running under. > > Eh? There may be some implementations like that but I'd be very > surprised if, when dprive is done, most implementations don't have > an is_doing_dprive() call they can make use of in application > layer code. I don’t see this as a problem either. There is already coupling between the transport and the content of the DNS message (TC=1) and other EDNS0 options are transport dependent (STARTTLS, edns-tcp-keepalive). > On 29 Jul 2015, at 15:12, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > >> 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. But… we do have running DNS-over-TLS code that we could improve today with padding. We do have operators interested in deploying DNS-over-TLS services. I think a good way to gather data on padding is to implement this option, but possibly with the ‘use with caution’ caveat suggested. Sara. _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
