On Thu, Jul 02, 2015 at 09:02:03PM +0300, Yoav Nir wrote:
> > 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.
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.
I think you mentioned that your design locates both the IP address
and the keys from DNS, so if the peers in the PAD database turn
rogue, they might subvert other peers, right?
> 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.
mallory.example is another domain in the PAD. Either domain can
return IP addresses that properly belong to someone else.
--
Viktor.
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
