Hi Paul, > On Jun 24, 2016, at 9:43 AM, Paul Wouters <[email protected]> wrote: > > 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 s y > 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?
yes, if identity hiding, efficiency, and incremental deployability matter; please see the rationale in Appendix A of https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-01. thanks David > > 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
