Re: [IPsec] draft-tjhai-ipsecme-hybrid-qske-ikev2-01

[Tero Kivinen <[e-mail]>]

Paul Wouters writes:
> On Mon, 12 Feb 2018, Valery Smyslov wrote:
> 
> >> This is one particular implementation peculiarity, there
> >> will be others that behaves oddly. The point is, if we introduce a new
> >> Transform Type, it is very likely that backward compatibility can no
> >> longer be achieved.
> >
> > Again, it depends. If the majority of implementations immediately crash once they
> > receive unknown transform, then I agree that we need another mechanism...
> > Most of other cases usually can be dealt with. Probably not all and probably
> > not as elegant as we wish, but still I believe they can.
> 
> We still have plenty of time to get the word out to those
> implementations to fix their problem. By the time we have a
> document ready for post quantum transforms, those implementations
> should have been fixed. It's a little early now to deem this
> an unsurmountable problem.

Yes. Also there is big difference in requirements for
draft-ietf-ipsecme-qr-ikev2 and requirements for proposal doing proper
quantum safe algorithms. The draft-ietf-ipsecme-qr-ikev2 is intended
to be deployed now, and should work with existing implementations
without fatal interoperability errors with them. 

As quantum safe algorithms itself are so much in ongoing research now,
I do not think we will be having implementations out there using any
of the quantum safe algorithms now, and so there will be time for
broken implementations to get fixes installed to them. I.e., if you
still plan on running completely broken strongswan implementation
which do not implement MUSTs in IKEv2 for example in year 2019, then
you are not interested in security, thus you are not really going to
be even try to use anything like quantum safe algorithms to talk to
them...

I mean, if you plan not to install security updates to your IPsec
products for years to come, it does not matter what we do, you most
likely have big security holes in your gateways anyways.

Even RFC4306 said you "MUST contain exactly one transform of each type
included in the proposal" in section 2.7, so what they are doing has
never been allowed in the IKEv2.

In the RFC5996 we did add text saying:

    If the responder receives a proposal that contains a Transform
    Type it does not understand, or a proposal that is missing a
    mandatory Transform Type, it MUST consider this proposal
    unacceptable; however, other proposals in the same SA payload are
    processed as usual.

and if they have not updated IPsec implemenation since 2010, again
there will most likely be so many holes in it that there is no point
of talking about quantum safe algorithms...

We have discussed several times of adding new transform types, and
in most cases we have found better ways of doing that. On the other
hand there is nothing that would make it impossible to add new
transform types. IKEv2 has been designed so that new things can be
added without breaking old implementations (provided old
implementations actually follow what was written in the IKEv2 RFCs).

In this case I think I agree with Valery that adding new transform
types might be good option, and we should investigate that option too. 

> > I prefer to reuse existing code for this and I see no reason why
> > it cannot be done. 
> I agree.

Making IKE_SA_INIT more complicated than what is now, is something we
do not really want to do. It is first exchange with the peer, it has
all kind of denial of service properties which we should try to cope.
We do not want to make it so big it will get larger than one kilobyte
in size, so it will not get fragmented by the IP layer etc. Doing
fragmentation on that layer is very hard if we want to protect that
also against DoS.

I am very much suprised that some of the vendors really said that they
wanted to change the IKE_SA_INIT instead than add new exchange between
IKE_SA_INIT and IKE_AUTH.
-- 
[e-mail]