On Fri, 24 Jun 2016, David McGrew wrote: Hi David,
Because QKD is not a practical system for Internet security. It has serious security issues/challenges and operational limitations on bitrate, range, and physical media. It requires a point to point optical link, which is typically dedicated fiber, which must be shorter than 60 miles. There are security issues with QKD because it relies on a physical interaction across the line between the encrypter and decrypter, thus giving an attacker the opportunity to perform an attack on the physical process anywhere on that line. See for instance Brassard et. al. Security Aspects of Practical Quantum Cryptography, Lydersen et. al., Hacking commercial quantum cryptography systems by tailored bright illumination, or Gerhardt et. al., Full-field implementation of a perfect eavesdropper on a quantum cryptography system. Another major security problem is the range limitation; it has been proposed to extend the range of QKD by using a chain of trusted repeaters, each connected by a QKD sy
stem. These repeaters would greatly increase the attack surface, and require the end user to trust the infrastructure provider(s); in contrast, the Internet community wants end to end encryption, as described in RFC3365 and RFC7624.
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. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
