On Fri, Mar 20, 2015 at 3:33 AM, Stephen Farrell <[email protected]> wrote: > > > On 19/03/15 23:43, Zhiwei Yan wrote: >> Hi, all, I think it's better that this draft contains some solution >> about the client authentication to decrease/avoid the DoS attack. But >> it's really not the focus of this draft. In order to solve this >> problem, many other schemes can be used, such as DHCP, SAVI and DANE. >> Anyway, this draft can make use of them to authenticate the client. > > I, and probably others, would fairly strongly object if the work > of this group that is intended to enhance privacy required all > clients to be authenticated, and hence identified, and thus give > up privacy. > > There may be a place for authenticated clients in this space (e.g. > perhaps within an Enterprise n/w) but that had better not be the > main mitigation for potential DoS attacks.
What's wrong with DNScrypt? Apparently people asked where the docs are: https://github.com/jedisct1/dnscrypt-proxy/blob/master/TECHNOTES. The writeup isn't the best, but it should be possible to see what is going on from this, and it seems very similar to the Wijngaards draft. Sincerely, Watson Ladd > > S. > > >> >> Best Regards, Zhiwei Yan >> >>> 在 2015年3月20日，上午12:02，Paul Wouters <[email protected]> 写道： >>> >>>> On Thu, 19 Mar 2015, W.C.A. Wijngaards wrote: >>>> >>>> Could perhaps a different algorithm, like ED25519, provide >>>> better performance, and would that performance then be adequate? >>> >>> Different algorithms differ in performance how much? A factor 2? >>> Maybe 10? Compared to a botnet, I don't think that it is very >>> relevant at all. >>> >>>> The draft allows negotiation of a symmetric key so normally a lot >>>> of asymmetric operations can be avoided by the use of a cache. >>>> >>>> For a cookie mechanism, there is the cookie draft from Eastlake >>>> and Andrews. >>> >>> Demanding source ip verification before allowing crypto seems a >>> very good idea with no real impact other than rejecting spoofed IPs >>> or old clients - and old clients won't support crypto anyway. >>> >>> Paul >>> >>> _______________________________________________ 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 >> > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
