Hi Paul, > On Jun 23, 2016, at 6:55 PM, Panos Kampanakis (pkampana) <pkamp...@cisco.com> > wrote: > > Introducing quantum computer resistance in IKEv2 helps to avoid the > implications of having sec admins that want to have quantum computer > resistance revert back to IKEv1 with shared secrets. The draft adds quantum > resistance using todays infrastructure. The qkd draft introduced a way to add > quantum resistance, but it came with many different challenges of how > practical it is and how costly it would be to introduce a QKD network. > Instead, draft-fluhrer-qr-ikev2 uses a more practical approach that could be > implemented and employed easily. Scott almost has a working PoC ready, I > believe. There are details that need to be hashed out in the group, like what > to do with identity hiding, but the draft is practical and can be introduced > quickly and in a backwards compatible way to IKEv2. > > Panos > > > -----Original Message----- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Wouters > Sent: Wednesday, June 22, 2016 3:33 PM > To: Waltermire, David A. (Fed) <david.walterm...@nist.gov> > Cc: IPsecME WG <ipsec@ietf.org> > Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an > IPSecME WG document > > On Wed, 22 Jun 2016, Waltermire, David A. (Fed) wrote: > >> At IETF 95 the chairs took an action to issue a call for adoption on >> draft-fluhrer-qr-ikev2-01 based on WG interest in the concept described by >> the draft. This call is long overdue. >> >> This is the official call for adoption of >> https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ as an IPSecME >> working group (WG) document. > > I still don't know if we should adopt this document or > > https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01 > > The qkd document was rejected for adoption at the time for lack of interest. > > I would like to better understand why draft-fluhrer-qr-ikev2 would be > prefered over draft-nagayama-ipsecme-ipsec-with-qkd.
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 syst em. 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. thanks David > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
