> On Jul 2, 2015, at 6:03 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > On Thu, Jul 02, 2015 at 05:13:01PM +0300, Yoav Nir 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)?
Not sure I follow. Mallory publishes - mallory.example.com IN A 192.0.2.5 - mallory.example.com IN TLSA .... But there’s also - alice.example.com IN A 192.0.2.5 - alice.example.com IN TLSA .... So Mallory can push people looking for his IPsec entity to go to Alice’s IPsec entity. Once there they might accept the public key they’re presented with (if he has copied the contents of the TLSA record) or not. Assuming Mallory cannot publish alice.example.com records, where is the attack? > 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. Paul is working on host to host IPsec for opportunistic encryption. The problem I would like to solve is that configuring the PAD is (1) hard, and (2) unwieldy, because any changes to your certificate requires updating the static configuration on all your peers. Yoav _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane
