On Tue, 31 Jul 2012, Michael Richardson wrote:
Paul> But my kernel SPD/SAD can only have one src:dst policy. In the case of
Paul> failure to do IKE, this would be a block to prevent plaintext leaks.
Paul> So if i can trick a client into connecting to paul.example.com, I can
Paul> ensure that user will not be able to talk to www.google.com.
This "attack" and the usage you gave for IPSECKEY is not consistent with
RFC4322.
Isn't it stating the same with different syntactic sugar?
4.3.2.1.in-addr.arpa. IN TXT X-IPsec-Server(P)=A.B.C.D public-key
So if I control the reverse 4.3.2.1 and trick you into a lookup for OE,
and put google's A.B.C.D with "boguspublic-key" in there, wouldn't I have
the exact same issue? And as per 4322, I could have my records DNSSEC
signed. It doesn't help google.
RFC4322 specifies it.
Section 3.2 discussed "OE-permissive" (fail-to-clear) and "OE-paranoid"
(fail-to-drop) versions. Openswan by default put the 0.0.0.0/0 into
OE-permissive policy bucket, so if IKE failed, then the "%hold" should
get replaced with a %pass.
So what happens in my case? Either google is blocked, or google is
downgraded to plaintext. Or the application could distinguish between
my suggested boguspublic-key versus the real google public-key. But
again, the only authoritave way for who controls A.B.C.D can be found
that reverse tree, which we deem unusable at large.
Paul> The core problem is that anyone can make a claim about someone elses'
Paul> IP address with respect to the public key. We have no way of knowing
"claim", yes, but not enforce.
OE failed initially because of lack of control over reverse, and later,
due to there being no reverse for systems on the NATwork.
Yes, and what I'm saying is that current methods for tying DANE to IPSEC
fail, because there is no binding to the legitimacy of the proclaimed
gateway.
The simple case where a server is doing OE for itself is not an issue.
That works, but I don't think that would move out of the hobby space.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
