The reverse failed. It is only useful in private cloud deployments lacking other types of authentication for publishing pubkeys (ldap, Kerberos , etc)
Sent from my iPhone > On Jul 2, 2015, at 19:01, Yoav Nir <ynir.i...@gmail.com> wrote: > > >> On Jul 3, 2015, at 12:28 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: >> >> On Thu, Jul 02, 2015 at 11:29:45PM +0300, Yoav Nir wrote: >> >>>> 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. >> >> Dynamic. >> >>> 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. >> >> Mallory can often trigger DNS lookups for her own domain, which >> can return IP addresses that collide with Alice's domain. How >> is that handled? > > RFC 4025 and Wikipedia suggest mapping the IPSECKEY record to the address > through reverse DNS. I don’t know in what percentage of the Internet that > would work. > > 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
