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

[David Schinazi <[e-mail]>]

Paul,

I understand your concerns, and I do agree with them. However, the proposal isn't meant to solve all issues - the idea is that if we're building a PPK infrastructure already, I believe this is an incremental improvement to it that solves a few more attack vectors without compromising anything.

> On Aug 16, 2017, at 09:50, Christopher Wood <[e-mail]> wrote:
> 
> On Wed, Aug 16, 2017 at 9:34 AM, Paul Wouters <[e-mail]> wrote:
>> 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)

On the contrary, if you were to run IPsec over point-to-point links between several mobile devices you own then you have a configuration that doesn't change much but devices that are very mobile - this allows you to have this type of configuration and ensure that there is no way for attackers to fingerprint who you are and where you go.

>> 
>>> [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.

I'm happy to hear proposals to make this a little better. Do you have an alternative that solves these use cases?

>>> [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
> 
> David's original email suggested that this technique was enabled by
> (and perhaps constrained to) draft-fluhrer-qr-ikev2, which assumes the
> existence of a long-term PPK.
> 
>> 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.

I don't see how adding a MAC in an extension data field is something the IETF can't handle. I'm being realistic here, and have an actual problem to solve. Are you telling me to go build and deploy my own proprietary solution instead of working with the IETF?

David