Subject: [IPsec] Direction for draft-tjhai-ipsecme-hybrid-qske-ikev2

From: CJ Tjhai <[email-masked]>
Date: Fri, 11 May 2018 09:55:14 +0100

Hi all,

Following the last IETF meeting, we would like to take the following
direction for our draft:

1. Negotiation: use KE payload as described in
draft-tjhai-ipsecme-hybrid-qske-ikev2-01. The main reason is backward
compatibility. Not all IKEv2 implementations out there are
RFC7296-compliant, while it is theoretically possible to upgrade them,
but we cannot guarantee that all of them would be upgraded. With the
approach described in draft-tjhai-ipsecme-hybrid-qske-ikev2-01, there
won't be any issues with backward compatibility.

2. There appeared to be a consensus in using an intermediary stage,
i.e. IKE_AUX, to transport the post-quantum key exchange payload.

3. There was also a suggestion in using a new payload type, e.g. PQKE
or QSKE, to carry the post-quantum key exchange payload.

What do people of think of this approach?

Thanks,
CJ

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 15 May 2018 17:48:24 +0300

Hi,

> won't be any issues with backward compatibility.

Well, this was discussed on the list and it is my impression, that
those who expressed their opinion (Tero [1], PaulW [2], myself [3]) 
prefer to re-use existing mechanism. I cannot recall that anybody
on the list or in London argued for using KE payload for negotiation.
Have I missed something?

I understand your concern about existence of non-compliant
implementations, but in my opinion adding QSKE into IKEv2
is not an immediate task, so there must be plenty of time
for vendors to fix their implementations. I don't want to 
introduce new negotiation mechanism when we already
have one that was specially designed for this purpose.

> i.e. IKE_AUX, to transport the post-quantum key exchange payload.

Agree.

> or QSKE, to carry the post-quantum key exchange payload.

I believe there will be no need for new payload if existing negotiation
mechanism is re-used. What is the reason for introduction of new payload?

> What do people of think of this approach?

Regards,
Valery.

[1] https://mailarchive.ietf.org/arch/msg/ipsec/lW4cFBLagNMdAx2VOSrz1z8VJF0
[2] https://mailarchive.ietf.org/arch/msg/ipsec/XqhkCN4u5vpRugE_Bg_TkP-hDGs
[3] https://mailarchive.ietf.org/arch/msg/ipsec/jahWqh_dvPkqAXnA4-C9LndtWWk