On Fri, Mar 20, 2015 at 6:33 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> 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. > > S. > There is message authentication, client authentication, device authentication and user authentication and they are very different things where privacy is concerned. One of the reasons why I am not keen on 'just' use TLS is that it forces one particular approach that is optimized for a different purpose. I find it much easier to provide the desired As far as DNS privacy goes, the big performance issue is the DNS lookup. We need to get latency reduced to the absolute minimum there and we need to have strong protections preventing people from DoS-ing the resolution hosts. For this particular interaction, my preference is for symmetric key based authentication using a kerberos style ticket to allow stateless key management on the server. The request is going to be encrypted, so we have a symmetric key at this point. So the question is how to establish a shared secret/ticket pair and how long it would be valid for. In the enterprise case we are going to require authentication of the user and/or device in order to connect to enterprise resources behind the split horizon. Here we will want to do a one time user/device authentication to establish a local credential. In the anonymous use case, the simplest approach might be to simply set up a TLS connection to the DNS service and request a ticket via a HTTP/JSON type interaction. That is what my current drafts describe. The problem with the purely anonymous case is that what our customers are currently paying us to provide is not actually 'privacy'. They are paying for a mechanism that bypasses local DNS based censorship and a curated DNS/IP address space that has the criminal element excluded. That makes things rather complicated because quite often a user may have different ideas about what censorship is good and which is bad. This is quite a challenging problem to get 100% right. But if the solution is less than 100% we are not going to get Microsoft, Apple or Google to deploy on the platforms 95% of the market uses.
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
