On Wed, Mar 11, 2015 at 01:25:24PM -0400, Phillip Hallam-Baker wrote: > On Wed, Mar 11, 2015 at 9:14 AM, Ilari Liusvaara < > [email protected]> wrote: > > > > > Another concern that I have is that the protocol has to protect resolver > > > hosts from a Denial of Service attack. That means that the hosts cannot > > > perform any function that provides an attacker with 'leverage' unless the > > > request passes authentication first. > > > > Denial of Service against network or Denial of Service against server? > > > > Both. > > > > The first can be addressed by limiting ratio of outbound to inbound data > > before client IP address is verified. > > > > Well we could pad requests... Or we could respond with a cookie challenge > if the response is too much larger than the request.
For network-DOS, allow association to be established, but refuse the piggybacked query. Real client can immediately repeat the query. > But in general, limiting the utility of the DNS is not the way to stop > amplification attacks. Authenticating requests is. That could be as simple > as a cookie or nonce but we should require some authentication as baseline. You mean level of "can receive packets sent to claimed source? > > The second presumably entails rate-limiting number of asymmetric key ops > > (since even moderate server can handle full-duplex 10Gbps symmetric > > encryption). > > Yes, Curve 25519 is fast enough for normal DNS client-resolver security but > not fast enough that the DoS attack vector can be ignored. Now, if one wanted to do verification of client IP before committing real crypto resources, that would require cookies. > > 2) Association establishment > > > > Use client configuration (from recon) to establish a temporary symmetric > > key (association) for encrypting requests and replies. > > > > OK, what I currently do is to establish a Kerberos style key in step 1 > which allows me to skip this step. But again, this is not something I am > fixed on. Given the progress in CFRG on ECC, I think using Curve25519 makes > a lot of sense. Another reason this step is there is to minimize long-lived secrets, especially on client. > > The complexity here needs to be low. In practicular, no nontrivial > > certificate parsing, no nvRAM programming. > > > > I don't see a need for certs at this level. I was thinking if to do one or two-level key scheme (the load for server is the same either way). > > For authoritative service, presumably server recon is done by > > querying the parent server and piggybacking requests on assoication > > establishment becomes more important. > > > That part worries me much less as once something is in my DNS resolver > cache I am going to refresh the records automatically on expiry rather than > wait for the first request after expiry. > > Cold cache requests are going to be pretty rare with this approach. Of course, there are lots of DNS servers around... > > The hard part is how you decide to set up the initial relationship between > > > the client and the resolver and how long you want it to last. > > > > Also, to note: Relationships involving longer-term secrets on client > > are not really feasible without changing the client side a lot since > > currently DNS config is public, and all programs are expected to be > > able to read it for their own stub resolvers. > > > That is potentially an issue on UNIX and certainly makes a good case for > your second stage. Is the DNS config currently secured (as in confidentiality) on Windows? (not that making daemons / services with private config files is impossible on either, just something that I think should be avoided in this case). -Ilari _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
