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. > 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? The first can be addressed by limiting ratio of outbound to inbound data before client IP address is verified. The second presumably entails rate-limiting number of asymmetric key ops (since even moderate server can handle full-duplex 10Gbps symmetric encryption). > 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. 2) Association establishment Use client configuration (from recon) to establish a temporary symmetric key (association) for encrypting requests and replies. If request is piggybacked on association establishment, care has to be taken to avoid DoS (network) attacks and using replay attacks to decrypt requests. The complexity here needs to be low. In practicular, no nontrivial certificate parsing, no nvRAM programming. 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. For authoritative service, presumably server recon is done by querying the parent server and piggybacking requests on assoication establishment becomes more important. > 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. [1] CPU => Central Processing Unit: Refers to amount of computation done. sRAM => scratch RAM: Memory that only lasts very short tern. pRAM => persistent RAM: Memory lasting moderate term (but still volatile) nvRAM => non-volatile RAM: Memory that persists across restarts. secure nvRAM => nvRAM with confidentiality protection. nvRAM programming => Writing to nvRAM. ROM => Read-only Mmeory: Firmware or program executable image. -Ilari _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
