> On Jul 2, 2015, at 10:40 PM, Viktor Dukhovni <[email protected]> wrote: > > On Thu, Jul 02, 2015 at 10:09:46PM +0300, Yoav Nir wrote: > >>> At the end of the day though, IPSEC needs to apply policy to >>> application traffic presented to the kernel (almost universally) >>> via the socket API. The socket API gives the kernel a transport >>> endpoint UDP/192.0.2.5/53, how is the kernel to decide whether to >>> use Mallory's keys for that same address or Alice?s. >> >> Host to host IPsec is very rare. VPNs are far more common and the packets >> don't get there by a socket API. > > The attack I had in mind is not an attack on VPNs. It is an attack > on IPSEC in transport mode. If you want to use DANE as a PKI for > VPN tunnel key management (where both the gateway IP and the key > material are provided via DNSSEC), that should work.
I agree, and I think that is something DANE can do. > The hard part is the transport-mode use-case. If the SPD entries are specific and pre-configured, the same reasoning as for VPNs applies. Things change if you want the SPD and PAD to be dynamic, such as reading them from DNS. There is RFC 4025 with the IPSECKEY record. So when the application performs a DNS lookup for www.example.com, the OS could also ask for an IPSECKEY record and get both public key and a gateway address. If we set the gateway address to be equal to the server address, this is the transport-mode use-case. Again, this all begins with the DNS name, so mallory cannot do anything. There are issues, though. if the application does not perform a DNS lookup (such as if the user entered http://93.184.216.34 instead of www.example.com) then the IPSECKEY entry is not read. RFC 4025 suggests using reverse DNS, but we know that reverse DNS doesn’t work too well. Yoav _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
