See my previously sent email. There is still a problem. I can explain more once I have a real keyboard
Sent from my iPhone > On Jul 2, 2015, at 17:29, Yoav Nir <ynir.i...@gmail.com> wrote: > > >> On Jul 2, 2015, at 10:40 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> 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 > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane
