On Wed, Mar 11, 2015 at 9:14 AM, Ilari Liusvaara < [email protected]> wrote:
> On Wed, Mar 11, 2015 at 08:26:13AM -0400, Phillip Hallam-Baker wrote: > > The proposal is a reasonable approach and not overly complex. The > question > > that concerns me though is how the client authenticates the resolver. > > Without authentication, encryption is useless because you could be having > > the conversation with Mallet. > > Well, not useless, but much less useful. OK, yes. Promiscuity is good. Everyone is for it nowadays. What I should have said is that we can't have a protocol that only supports promiscuity and does not support long term relationships. > > 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. 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. > 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. > > > > So the first thing I think is necessary in any proposal is to separate > out > > the problem of how the client-resolution service context is established > > from the mechanism used to enhance the DNS packets. The second part of > the > > proposal is very straightforward. A simple framing scheme using the tools > > already present in the TLS toolkit can be devised and implemented in few > > hours. Supporting parallel UDP and TCP or even UDP and HTTPS schemes is > not > > a major overhead. > > I would split the thing into three layers for recursive service: > > 1) Server recon > > Determine what the server supports, perform validation of server/provoder > public key, determine server IP addresses if needed. Save the results > in client configuration. > > Moderate complexity is available here, along with nvRAM programming, > but no secure nvRAM. > Agreed. For this I propose using JSON over HTTPS and aligning the protocol with ACME as far as practical. I have a draft but I don't particularly care about the details. 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. > If request is piggybacked on association establishment, care has to > be taken to avoid DoS (network) attacks and using replay attacks to > decrypt requests. > Yep. > 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. > 3) Symmetric operation > > Use established assocation to encrypt DNS requests and replies. > > The operation here is essentially constrained, which means extremely > low CPU, pRAM[1] and ROM usage. No nvRAM available at all. Asymmetric > crypto can't be used. > Agreed. At this stage the protocol has to be stateless. So kerberos style tokens for session description. > 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. > 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.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
