On 13 Dec 2016, at 6:46, Shane Kerr 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.
IPsec will always have worse characteristics for DOS than DTLS, and
probably worse than TLS. Why do want it to be an option here?
The other alternative is to invent some novel crypto (fun but
ill-advised)
If what we invent has better characteristics than DTLS or TLS, that
means that the TLS WG failed to find something that we could. That seems
*incredibly* unlikely, given the people active in the two WGs.
or steal some equivalent (like the crypto part of
DNScurve, also mentioned in the draft).
The "crypto part of DNScurve" could be added to (D)TLS.
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? ;)
Yes.
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.
Why do you think it would not be accepted? It could be used where
available, and fall back to current authentication when it isn't.
Otherwise I think we should lean towards putting authentication tokens
in the DNS itself.
OK, now I'm confused. I thought this is what you meant by "CGA
approach". Can you explain the difference?
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.
The draft drifts towards that, but I don't think it is the right problem
statement. Instead, we should be going towards "encrypt wherever
possible, but don't limit yourself if you can't."
--Paul Hoffman
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
