On Thu, 2 Jul 2015, Viktor Dukhovni wrote:
The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP
address and a DANE record. The DANE record can be used to identify the
certificate or raw public key used in IKE.
What prevents IP address hijacking (mallory.example publishes
alice.example's IP address and now mallory's IPSEC keys are used
to encrypt traffic to alice)?
This is the biggest problem yes. At best, you can detect you got
two different IPsec pubkeys for the same IP (say 8.8.8.8) and
then you have to disconnect both to prevent encrypting to the attacker.
(eg if i put in evil.nohats.ca. IN A 8.8.8.8 along with an IPSECKEY
and have you trigger opportunistic IPsec to evil.nohats.ca)
Of course, a layer of NAT or one-local-ip-per-remote could address
that but it is extremely ugly. So we (libreswan) are still undecided.
I thought that Paul Wouters is working on a more comprehensive
specification, IIRC in an IPSEC working group where it can get
better informed review. This is much more of an IPSEC design
problem, than a DANE design problem.
Yoav is one of the core IPsec people, so that's good :)
Once the IPSEC parts are in good shape, perhaps the document can
be discussed here for any final DANE-specific issues (details of
just the DANE RRset used for the document).
I'm not sure if we need a new record. We could use IPSECKEY with
some restrictions (gateway option must be unused)
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
