On Mon, 13 Apr 2015, Daniel Migault wrote:
Just for information, what are the technical reasons IPsec has not
been considered at all for providing DNS
privacy.
People can already use an IPsec VPN and a remote DNS server without
anything new from IETF?
I do not see what prevents securing communications to IP_DNS or FQDN_DNS with
IPsec, either using transport or tunnel mode.
Encrypting is not the problem, authenticating is.
I think additionally, IPsec has a higher barrier to entrance because it
needs more priviledges to build a system host tunnel as compared to an
application encryption tunnel like (D)TLS.
This is partly true, especially if you use UDP encapsulation. If you do not use
UDP encapsulation, cannot it be possible to build your
packet over a raw socket. -- but that is right it may be still a bit more
difficult. If you use the IPsec kernel implementation, then
the only disadvantage I would see is a lake of interactions between the
application and the SPD for alternatively a secured and
non-secured DNS.
Yes, people are already unhappy with applications needing dnssec
processing libraries for true validation into the application. Adding an
IPsec stack would be far worse. Also, you would not be able to run IKE
on the regular IKE port, so this quickly becomes far more complicated
than TLS. (and far more complicated than a preconfigured IPsec VPN to 8.8.8.
Also, IPsec does not yet
allow the client to remain anonymous - although we're almost done that
part with draft-ietf-ipsecme-authnull. And you _can_ already use that
if you support IKE authnull to 193.110.157.123 (although it does not
yet support one-sided auth where the IKE client verifies the IKE server)
In addition there is also BTNS. RFC5386
But BTNS requires kernel changes, and I am not aware of any kernel
implementation of BTNS.
Having an IPsec protected DNS connection is a very good and solid
solution. But an individual application cannot decide to use such
encrypted DNS. Using an application based (D)TLS would allow an
application to make encrypted DNS possible without requiring the system
core OS to have some support for that.
I see that as the "higher barrier to entrance" you mentioned earlier.
The use of IPsec could re-use existing extensions like NAT
traversal, compatibility with UDP/TCP, resilience to
change of IP
addresses... and this without creating new extensions.
But you get those as well using (D)TLS ?
Yes of course, but the point is that you need both TLS and DTLS for the TCP/UDP
compatibility.
I would hope that recursors implementing dprive, would also have long
lived TCP connections, so that we wouldn't need UDP.
Paul
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
