On Wed, 14 Dec 2016 12:40:25 +0100, Shane Kerr wrote: >John, > >At 2016-12-13 10:01:51 -0800 >John Heidemann <[email protected]> wrote: > >> >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? ;) >> >> Can you please clarify, what is the problem IPsec or novel crypto is >> trying to solve? > >Encrypting the session between the resolver and the authority server? ;)
Of course. But rfc7858 could already cover that case with DNS-over-TLS, so presumably you have some *additional* set of constraints you care about, for which IPsec or novel crypto improves over rfc7858. > >I am just enumerating the options as I understand them. As Stephane >points out, both IPsec and novel mechanisms have been proposed for this >problem; and neither by me! Exploring and comparing options is well worth doing. I was hoping to get a clearer problem statement to make that comparison. There's a bunch of possible trade-offs: client latency, server memory, client memory, novelty vs. maturity of design, maturity of libraries, support by other groups, design complexity, ... You suggested earlier in the thread that rfc7858 was weaker than some alternatives for recurisive-to-auth traffic, so I was trying to figure out for which metrics you think it is weaker. -John _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
