Stephane, At 2016-12-13 11:59:36 +0100 Stephane Bortzmeyer <[email protected]> wrote:
> In the minutes of the Seoul meeting, we see: > > Strong hum for sticking around to work on this. > Terry (as AD): more mailing list discussion, please > > So, this email is to request this > discussion. draft-bortzmeyer-dprive-step-2-04 is published, with all > the remarks from the Seoul meeting integrated. Now, it is time to give > an advice on things like: > > 1) Use TLS for the resolver-to-auth link, or not? I think that TLS may be more painful in the resolver-to-auth case, as TCP Fast Open will be generally less useful, right? But what are the other alternatives? DTLS is mentioned in the draft. Do we have any benchmarks or simulations as to the expected relative benefits of DTLS vs. TLS for DNS? IIRC the idea of using IPsec was also discussed somewhere. IIRC, IPsec may have problems traversing NAT. It is also usually implemented by the kernel, which may cause deployment issues. I *want* IPsec to be an option here, but realistically I don't think it is. The other alternative is to invent some novel crypto (fun but ill-advised) or steal some equivalent (like the crypto part of DNScurve, also mentioned in the draft). After TSIG, DNSSEC, DNS cookies, and the rest, it would be weird if DNS used something standard, but maybe we can try it for once? ;) > 2) Which authentication(s) to use? I really like the CGA approach, but realistically I don't think that would be accepted. If we think that it would be, then I'm all for it. ---- Otherwise I think we should lean towards putting authentication tokens in the DNS itself. AIUI the draft, if we want to use DNS the problem is that we want to know how to encrypt a session to a name server, but we can't look up anything about the name server in the DNS because we don't yet know how to encrypt a session to the name server. Is it possible to tie the authentication to the domain instead of the name server? We could say sessions looking up EXAMPLE.COM use certificate 1234, regardless of which name server they are talking to. If we could do this, then we could even publish certificate 1234 in a DS record, and then it would be returned by the parent. (We can use a new type for this, which is more elegant but requires server modification and protocol changes.) There are several advantages of this: * no bootstrapping issues * no modification to existing software needed for parents * an observer/attacker cannot know that a resolver is going to use an encrypted session unless they observe the actual session between the resolver and authoritative server (which is unavoidable) Also some disadvantages: * a single authoritative server may have to configure thousands of certificates (although of course this is less of a problem for hosters that are the masters of the zones, as they can share certificates between zones) * keys must be shared across administrative boundaries (that is, if I use Dyn and FreeDNS for hosting, then both hosters can impersonate the other or decrypt traffic to the other) * resolvers can't just store certificates with the name server information * could be interpreted as another layer of indirection in the DNS ;) Cheers, -- Shane
pgpCldtb7UAwc.pgp
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
