Re: [IPsec] Privacy attack vectors against IKEv2 and Postquantum

[Paul Wouters <[e-mail]>]

On Mon, 14 Aug 2017, David Schinazi wrote:

> [DS] I think "showing ID" is exactly what we're avoiding here. You can think of this in terms of the Socialist Millionaire Problem - we want to be able to assert identity without anyone disclosing anything first. And the proposed solution is to send a MAC without the identity of the key used to MAC. Peers can than iterate their list of peers to check the MAC against.

But when you are using X.509 based clients, you will have never seen the
cert/ID until you receive it via IKE ? So your use case is limited to
very static type deployments (which suffer less from this issue as they
tend to not move around)

> [DS] Some security is still better than less security, you can imagine timing attacks and such but this is better than what we have today.

But I think we would need something a little better to make it part of
an RFC standard.

> [DS] I was initially going to make this a separate proposal that only involved a pre shared key and SA_INIT MAC, but it was pointed out to me that once you have that might as well include the benefits of PPK. If you know of a way to solve the described privacy attack vectors without a pre shared key and without adding round trips, I'm interested - I couldn't come up with one myself.

A PreSharedKey based solution is also very limiting, and people should
be migrating away from PSK in favour of RSA/ECC based solutions :P

I understand your use case (prevent blocking of hidden IKE over TCP/TLS
servers) but it might not be a use case the IETF can solve. From an
IETF perspective, the way to solve this would be to IPsec everything,
so that blocking based on ESP visibility becomes impossible. Which
is why I'd like to see more Opportunistic IPsec.

But if we can fit in your goal, that would be great. And I think if
that takes another roundtrip people can make that decision. But I
think nation state actors are already active attackers, so I see
not too much value in a passive attackers only solution, which
IKE over TCP/TLS already is.

Paul