> On Jul 3, 2015, at 5:07 PM, Paul Wouters <[email protected]> wrote: > > 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.
Seems like a limitation of DNS security. DNSSEC can authenticate that “mallory claimed that mallory.example.com is at 8.8.8.8”, but DNSSEC does nothing to tell me whether the claim is true. Ordinarily you gain nothing by pointing your DNS name at a wrong IP address. What you are proposing is to use DNS queries to build a reverse directory in the SPD+PAD. You resolve mallory.example.com and get an IP address (8.8.8.8) and a TLSA (or IPSECKEY) record. You use that to build a database that uses the IP address as key and maps 8.8.8.8 to the pubkey in the IPSECKEY record. So you use the value 8.8.8.8 which nobody other than mallory vouches for, and which nobody guarantees us uniqueness for, and you use it for a key. This fails even without malice. Suppose both www.example.com and tools.example.com are on the same server. We can get the right identity by using IDr in IKE_AUTH or SNI in TLS. Depending on which of these you resolved last, you will get a mapping in the SPD from 93.184.216.34 to one of the public keys. You will use that to initiate IKE, and you might use the wrong one. If we really wanted secure opportunistic, we’d need to authenticate claims tying IP addresses to names. Perhaps the resource PKI from BGP security could get us there. Yoav _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
