Also, it appears that part of the motivation for this is to provide
confidentiality protection to DNS. The DPRIVE WG is chartered to work
on confidentiality protection for DNS queries and responses:
http://datatracker.ietf.org/wg/dprive/documents/
Any IPsec-based proposals for DNS confidentiality would seem to belong
in DPRIVE WG, not DANE WG. DPRIVE's approach seems to be: secure the
stub resolver to recursive resolver connection. IPsec fits in that
approach, and all that's needed is traditional IPsec configuration
learned from DHCP or DHCP plus DNS. Even then, implementation-wise it's
much easier to use TLS[0] as all the current proposals in DPRIVE WG do.
For other use cases, IPSECA would only help if it were utterly trivial
to use, and -better yet- if it could just be used automatically. But
the latter is non-trivial: existing applications use connect() and they
don't tell it the name of the server they want to connect to, only an IP
address. ISTR hearing someone say that "hey, the system could match
lookups to connects", but I don't believe that's a good idea. So you
can't have this just happen; new APIs would be required, full stop.
[0] Because using IPsec from applications is just ETOOHARD, even for
system applications like a name services daemon.
Nico
--
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
