The IPSECKEY issue came up a few times today in the dane meeting without
being explained. This is the issue (see https://tools.ietf.org/html/rfc4025 )
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> "Paul" == Paul Wouters writes:
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 th
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> en
> "Paul" == Paul Wouters writes:
Paul> So what happens in my case? Either google is blocked, or google is
Paul> downgraded to plaintext. Or the application could distinguish between
Paul> my suggested boguspublic-key versus the real google
Google is plaintext, you never had the r
