Hi >> Well, that are valid reasons. However, what makes me uncomfortable is that >> this design >> looks like yet another short-term (or medium-term) solution. We already have >> draft-fluhrer-qr-ikev2 that was declared as a temporary short-term approach >> to countermeasure >> immediate threat until cryptography science gives us new well-studied >> QC-proof primitives to >> replace classic public key cryptography. Now it turns out that we don't have >> primitives we >> are certain in (at least for key exchange), so we decide to combine several >> different >> primitives (which we don't fully trust in) with classic DH. That's a valid >> approach for >> transition to PQ cryptography, but it doesn't look like long-term standard >> solution.
On our draft-00, one of the objectives is to deprecate DH key exchange in the long-term future. Hence, we thought it would be neater to introduce a new transform type and a new PQ key exchange payload (QSKE). The idea is that when people are happy to drop KE payloads, they can use QSKE payloads instead. Obviously, there are concerns with backward compatibility by introducing a new transform type, which I agree. However, the issue with large payload size of post-quantum key exchange needs to be resolved regardless. Hence, the discussion has been focused on this since. Is KE payload mandatory? One thing that we thought about is to use keep KE payload and exchange post-quantum blobs in this payload and use a bit of the reserved field to indicate that this is a large payload that potentially needs to be treated differently. In this way, there is no need use another KE payload but there could be issue with multiple KEs in IKE_SA_INIT when both classic and PQ KE primitive are used. >> What particularly makes me unhappy: >> - the design looks like violation of the "gold rule" of cryptography - >> "don't combine >> several week primitives, it doesn't add to security, instead use one strong >> primitive" >> (I understand that each rule has exceptions, so that's probably the case, >> but still) Before people are happy with PQ algorithms, it is acceptable to combine classic and PQ, as the security of IKE is not weaken. >> - when (and if) workable QC appears, the classic DH exchange will provide >> zero security, >> but will still consume resources, that will just be wasted. And the proposed >> design doesn't >> allow to get rid of DH completely, so the resulting protocol will be >> inefficient. >> >> So we end up with yet another temporary solution. That's not good. I totally agree with you on inefficiency issue here, but having DH may not decrease security. It would be great to hear from the WG whether we should look into the needs in dropping DH at this stage. Best regards, CJ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
