Comments below. > > In contrast, QR-IKEv2 can be used to add postquantum security between > any two points on the globe, without requiring dedicated fiber, and without > requiring physical layer security assumptions. It has *fewer* security > assumptions than draft-nagayama-ipsecme-ipsec-with-qkd, as that draft > relies on the security of symmetric cryptography and the physical layer, > whereas QR-IKEv2 relies only on the former. > > For a postquantum IKEv2 extension, does it matter which underlying > mechanism is used to provide the extra bits to mix into the SKEYSEED? > > I think what is needed is: > > - A NOTIFY message that signals an identifier of where the extra bits > should be taken/generated from. Both endpoints have previous > knowledge > of what tjos identifier refers to. Be it a hardware device or an > offset in a onetime pad, etc, etc. > > - A specification on how to mix in these extra bits into SKEYSEED generation > to gain postquantum security. > > - Any additional counter meassures (such as increased minimum keysizes) > > Do we need to know if these bits came from a QKD link, a QR link, or a > mutually shared onetime pad? If not, then these specifics should not go into > such an ikev2 extension.
Could this be done in multiple drafts? One to generalize the approach and other drafts to discuss the acquisition methods (e.g., QKD link, QR identifier, etc). Thanks, Dave _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
