The problem is two different keys in two different domains in combination with traffic hijacking.
If I steal your 8.8.8.8 route, and trick you into looking up and doing IKE to my domain google.nohats.ca with A record 8.8.8.8, you start encrypting all google DNS to me. That is, your applications do not know the encryption of 8.8.8.8 is setup using ipseckey records not from google. There is a disconnect between system and application with IPsec that you do not have with TLS or SSH Normally this is hard, but in coffee shop wifi it would be easy. Sent from my iPhone > On Jul 2, 2015, at 15:02, Yoav Nir <[email protected]> wrote: > > >> On Jul 2, 2015, at 8:08 PM, Viktor Dukhovni <[email protected]> wrote: >> >> On Thu, Jul 02, 2015 at 08:04:37PM +0300, Yoav Nir wrote: >> >>>>> Not sure I follow. Mallory publishes >>>>> - mallory.example.com IN A 192.0.2.5 >>>>> - mallory.example.com IN TLSA .... >> >> Mallory publishes her own TLSA record for keys she possesses. >> >>>>> But there's also >>>>> - alice.example.com IN A 192.0.2.5 >>>>> - alice.example.com IN TLSA .... >> >> Alice's keys are ignored once Mallory's PAD entry for 192.0.2.5 >> supercedes or displaces Alices. > > Ah, I see the source of my confusion. > > I never think of a PAD as a table indexed by IP address. The “key” for the > PAD is a peer, so in practice it might be indexed by an internal name (such > as the “conn” labels in the ipsec.conf file in all *swan implementation) or > it might be indexed by the content of the ID payload that we expect that peer > to present in IKE. > > There is no entry for 192.0.2.5. I’m suggesting that there should be a > static entry in the PAD for “alice.example.com”. DNS is used to resolve this > to an IP address and to a public key. Unless mallory can affect > “alice.example.com” entries, the victim never gets to see his records, > because she never looks for them. > > Yoav > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
