Subject: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Wed, 22 Jun 2016 17:30:08 +0000

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. 

By adopting this draft, the WG is agreeing to take this on as an official WG item to continue work on the draft. Please reply with any comments supporting or concerns against adopting to the mailing list. This call will run until Friday, July 4th UTC 23:59.

Thanks,
Dave and Tero

---

From: Paul Wouters <[email-masked]>
Date: Wed, 22 Jun 2016 15:33:00 -0400 (EDT)

> 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.

Paul

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 23 Jun 2016 22:55:17 +0000

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:[email-masked]] On Behalf Of Paul Wouters
Sent: Wednesday, June 22, 2016 3:33 PM
To: Waltermire, David A. (Fed) <[email-masked]>
Cc: IPsecME WG <[email-masked]>
Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document

I would like to better understand why draft-fluhrer-qr-ikev2 would be prefered over draft-nagayama-ipsecme-ipsec-with-qkd.

Paul

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Jun 2016 21:06:00 -0400 (EDT)

On Thu, 23 Jun 2016, Panos Kampanakis (pkampana) wrote:

> The draft adds quantum resistance using todays infrastructure.

So did the old draft?

> 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.

This is sort of answering the question by just rephrasing the question
as an answer :P

As I understand it, both drafts depend on exchanging an identifier in
the clear, that leads to identifying an out-of-band PreSharedKey. This
is then mixed into the prf/prfplus.

The drafts use different ways to accomplish this. (and I think both are
too complicated)

> 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.

I don't understand why the use of AES and SHA256 hardcoded in the
document? Why isn't the ID enough to gain access to the new PSK?
If the source of the PSK is not fast or good enough to create
enough key material, why doesn't the out-of-band process do its
own PRF function? I don't see why that needs to be in this specfication.

Why use ECB? I thought this algorithm had fallen out of favour?

I don't yet understand why the child sa also needs to be modified. Do
we think that the prf() is insecure if the EC(DH) is broken? If the
IKE SA is broken, what other attacks are possible? IKE SA deletion?

How does this work with session resumption?

I thought for IKEv2, we realised that anonimity is hard to protect
for against an active attacker, as the initiator always has to
out itself somehow for the responder to be authenticated. As such,
I think the fourth "stated goal" might not be worth it, and everything
could be simplified further. And it would remove the whole extra
exchange with cookies too.

The simplest implementation I see, which would also work with a shared
onetime pad, is to just send some kind of notification that IDs the
source for the additional key material, then whenever we draw from
an IKE prf(), throw in some of that keymaterial. I don't yet see the
real advantage of anything more complicated then that.

Paul

---

From: David McGrew <[email-masked]>
Date: Fri, 24 Jun 2016 06:06:00 -0400

Hi Paul,

> On Jun 23, 2016, at 6:55 PM, Panos Kampanakis (pkampana) <[email-masked]> wrote:
> 

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 system.  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

---

From: Rodney Van Meter <[email-masked]>
Date: Fri, 24 Jun 2016 20:33:57 +0900

> On Jun 24, 2016, at 7:06 PM, David McGrew <[email-masked]> wrote:
> 
> Hi Paul,
> 
>> 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.

Note that the QKD draft talks in terms of QKD, but the mechanisms developed are in fact generic to out-of-band generated key material that must be named and agreed on.  The last status of the nagayama draft was that there was resistance to the concept of QKD from some quarters, and less resistance from others but no sense of urgency.

We were encouraged by the ADs and a few others to rework the draft to focus more on generic uses of out-of-band generated key material, but we haven’t managed to put together the right set of hours to get it done. At least one person said, “It may be snake oil, but you’re entitled to interoperable snake oil,” with reference to the fact that we want a published document that has had input and review and improvements, but certainly recognize that the use case remains a specialized corner for the moment. But given the work being done to standardize other parts of QKD inside ETSI, it seems important to have matching IPsec hooks that will be common, and it’s especially important to me that IETF retain control to any changes to IPsec, rather than having another standards organization documenting changes to protocols developed here, which certainly seems a recipe for nightmarish politics and non-interoperable implementations.

draft-nagayama-ipsecme-ipsec-with-qkd went through both -00 and -01 drafts a significant time period apart. The protocol in -00 represents our actual implement with actual QKD devices, from some time ago. Shota was working at one point to modify the code to match -01; he would have to remind me how close to complete that code is. The source for the -00-compliant version is downloadable at
http://aqua.sfc.wide.ad.jp/research/ipsecwithqkd.html <http://aqua.sfc.wide.ad.jp/research/ipsecwithqkd.html>

		—Rod

---

From: Paul Wouters <[email-masked]>
Date: Fri, 24 Jun 2016 09:43:07 -0400 (EDT)

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…

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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 24 Jun 2016 09:45:49 -0400 (EDT)

On Fri, 24 Jun 2016, Rodney Van Meter wrote:

> We were encouraged by the ADs and a few others to rework the draft to focus more on generic uses of out-of-band generated key material,
> but we haven’t managed to put together the right set of hours to get it done. At least one person said, “It may be snake oil, but you’re
> entitled to interoperable snake oil,” with reference to the fact that we want a published document that has had input and review and
> improvements, but certainly recognize that the use case remains a specialized corner for the moment. But given the work being done to
> standardize other parts of QKD inside ETSI, it seems important to have matching IPsec hooks that will be common, and it’s especially
> important to me that IETF retain control to any changes to IPsec, rather than having another standards organization documenting changes
> to protocols developed here, which certainly seems a recipe for nightmarish politics and non-interoperable implementations.

Agreed. Those groups should really come out of the dark and discuss
their proposals at the IETF.

Paul

---

From: David McGrew <[email-masked]>
Date: Fri, 24 Jun 2016 10:05:59 -0400

Hi Paul,

> On Jun 24, 2016, at 9:43 AM, Paul Wouters <[email-masked]> wrote:
> 

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

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 24 Jun 2016 14:58:24 +0000

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.
> 
> 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

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 24 Jun 2016 15:26:08 +0000

> From: Paul Wouters [mailto:[email-masked]]
> Sent: Friday, June 24, 2016 9:43 AM
> To: David McGrew (mcgrew)
> Cc: Waltermire, David A. (Fed); IPsecME WG; Scott Fluhrer (sfluhrer); Panos
> Kampanakis (pkampana)
> > 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.
> >

One possible concern is whether such a notify message would compromise the anonymity properties of IKE; if someone in the middle sees the same identifier in multiple exchanges, would they be able to conclude that those are the same individuals negotiating?  If the NOTIFY messages are anonymized, how is that done?

Now, it might be that the WG would decide to compromise on such anonymization concerns; this would simplify things a lot, however it's very much something we need WG agreement on.

>    to gain postquantum security.

The reason we specify modifying the public nonces (rather than doing a more fundamental change to the skeyseed computation) was to minimize changes to the IKE implementation itself (and in particular, the crypto parts).  Is there a reason why we wouldn't continue with this approach?

> - Any additional counter meassures (such as increased minimum keysizes)

And what algorithms are suggested (e.g. XCBC and CMAC both don't work, as the standard IKE versions are fixed to 128 bit keys)

---

From: Rodney Van Meter <[email-masked]>
Date: Sat, 25 Jun 2016 07:03:53 +0900

> 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.

All of these things are true for existing technology.

>   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.

The technology is evolving rapidly.  We can now talk about the
existence of a quantum IT industry; there are billions of dollars of
government and VC and big company money, and at least a dozen startups
that are out in the open, half in quantum computing and half in QKD.
Over the next few years, a lot will happen.

Most importantly in this context, it's very important to recognize
that there is a YUUGE technological difference between networks that
create and use long-distance quantum entanglement, versus those that
use only quantum effects on single photons.  Entanglement-based
networks are way harder to build, but will solve the distance
problems and enable many applications besides just QKD.  

If appropriate constraints on architecture (both hardware and
protocols) are put into place at the beginning, I believe it is also
possible to *guarantee* that the system avoids the kind of hacks that
plague existing QKD systems; the keys are the need to perform certain
quantum operations on quantum data (qubits) that are *optically
isolated* from the (possibly compromised) inter-node channel, and to
have adequate classical random number generators available each node.
But that's an area where things are still kind of settling out, and
it's not yet technically feasible.

I gave a talk last year at Verisign on applications of quantum
networks, focusing on *entangled* networks. I divide quantum
networking apps into three areas: distributed cryptographic functions,
sensor networks, and distributed digital computation.  QKD sits at the
border of dist crypto and sensors.

If you know nothing about the topic, I suggest you start at the
beginning, but if you want to skip the background (at any rate, all
done without any serious math), scroll forward to the 20:30 mark,
where the discussion of classes of applications of distributed
entanglement begins.  At 23:50, I begin discussing QKD.  At about
27:00, I start discussing different usage scenarios in a way that I
think is particularly relevant to this conversation.
https://www.verisign.com/en_IN/innovation/verisign-labs/speakers-series/quantum-networks/index.xhtml

Apologies, but one more plug for our work: in 2014, I published a book
on Quantum Networking.
http://as.wiley.com/WileyCDA/WileyTitle/productCd-1848215371.html
(Apologies for the horrific price, I didn't set it and I'm appalled.)
There is only a little discussion of QKD in it, but there is a lot of
basic background on quantum teleportation and discussion of
leading-edge work on quantum repeaters.  The last third of the book is
about quantum *networks* (as opposed to just chains of repeaters), an
area where my research group is just about the only group in the world
working.  We recently published a paper on quantum *internetworking*,
http://arxiv.org/abs/1508.04599.

On a different topic, IEEE has recently started a standardization
project aimed at interoperability at the network control level, using
software defined networking (SDN for QKD), P1913 - Software-Defined
Quantum Communication,
https://standards.ieee.org/develop/project/1913.html.

Enough for now,

       --Rod

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 28 Jun 2016 11:59:14 +0300

Hi,

I support adopting this document. I think we need to have a PQ-secure solution in IPsec.
I'd like to see it generic enough and not limiting to QKD technology only. I'd also like
to have IKE SA to be protected, as well as Child SAs, so that this solution can be used
in cases when sensitive data is transferred over IKE SA (like in G-IKEv2).
I think the draft is a good starting point, which by no means excludes collaborations
with authors of draft-nagayama-ipsecme-ipsec-with-qkd (or with others) during
the work on this document (if it is adopted).

Regards,
Valery.

> 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.
>
> By adopting this draft, the WG is agreeing to take this on as an official WG item to continue work on the draft. 
> Please reply with any comments supporting or concerns against adopting to the mailing list. This call will run until 
> Friday, July 4th UTC 23:59.
>
> Thanks,
> Dave and Tero
>

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 28 Jun 2016 18:12:54 +0000

This has been a good discussion so far. There is work to be done to address the issues raised.

Getting back to the call for adoption, I'd like to see feedback on the following questions to better understand where consensus is on this issue.

1) Previous WG discussions have indicated interest in this problem. Does the working group think that there is a problem here that we need to address?
2) Should we do this work in the IPsecME working group? If not, where?
3) Can we use draft-fluhrer-qr-ikev2 as a starting point for developing a WG solution to this problem? If not, what is a suitable starting point instead?

Regards,
Dave

> From: Scott Fluhrer (sfluhrer) [mailto:[email-masked]]
> Sent: Friday, June 24, 2016 11:26 AM
> To: [email-masked]; David McGrew <[email-masked]>
> Cc: Waltermire, David A. (Fed) <[email-masked]>; IPsecME WG
> <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>
> Subject: RE: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME
> WG document
> 
> 
> > Cc: Waltermire, David A. (Fed); IPsecME WG; Scott Fluhrer (sfluhrer);
> > Panos Kampanakis (pkampana)
> > 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
> > 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
> > 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.
> > >
> > relies on the security of symmetric cryptography and the physical
> > layer, whereas QR-IKEv2 relies only on the former.
> >
> One possible concern is whether such a notify message would compromise
> the anonymity properties of IKE; if someone in the middle sees the same
> identifier in multiple exchanges, would they be able to conclude that those
> are the same individuals negotiating?  If the NOTIFY messages are
> anonymized, how is that done?
> 
> Now, it might be that the WG would decide to compromise on such
> anonymization concerns; this would simplify things a lot, however it's very
> much something we need WG agreement on.
> 
> >
> The reason we specify modifying the public nonces (rather than doing a more
> fundamental change to the skeyseed computation) was to minimize changes
> to the IKE implementation itself (and in particular, the crypto parts).  Is there
> a reason why we wouldn't continue with this approach?
> 
> >
> And what algorithms are suggested (e.g. XCBC and CMAC both don't work, as
> the standard IKE versions are fixed to 128 bit keys)
> 
> >
> > mutually shared onetime pad? If not, then these specifics should not
> > go into such an ikev2 extension.
> >
> > Paul

---

From: Rodney Van Meter <[email-masked]>
Date: Thu, 30 Jun 2016 17:58:52 +0900

> On Jun 29, 2016, at 3:12 AM, Waltermire, David A. (Fed) <[email-masked]> wrote:
> 

I think it’s pretty clear that a mechanism for using keys created in some out-of-band fashion for keying symmetric encryption methods, such as AES, is valuable.

> 2) Should we do this work in the IPsecME working group? If not, where?

Here.

> 3) Can we use draft-fluhrer-qr-ikev2 as a starting point for developing a WG solution to this problem? If not, what is a suitable starting point instead?

Neither Shota nor I have sat down and reviewed this in detail, so I can’t really comment yet, but I’m happy to support whatever results in the best standard, whether it’s starting from fluhrer or from 
https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01 <https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01>

It’s important to me that the mechanism support not just *pre-shared* keys, but dynamically created keys from *any* out-of-band mechanism, within constraints that probably need to be defined carefully. If that’s done right, it can be used to support QKD-generated keys, or a daily or weekly courier.

One of the biggest technical issues, and one that hit us, was what to do when the key generation channel is disrupted. We proposed a set of fallback options in that draft, which generated significant controversy.

I *don’t* think it’s yet appropriate to work on one-time pad, as I think that results in more complex changes to IPsec than is reasonable to bite off.

Tero was perhaps the person who reviewed our work most carefully, so is probably the best qualified person to determine the relative merits.

		—Rod

---

From: Paul Wouters <[email-masked]>
Date: Thu, 30 Jun 2016 05:17:32 -0400 (EDT)

> I think it’s pretty clear that a mechanism for using keys created in some out-of-band fashion for keying symmetric encryption methods, such as AES, is valuable.

Yes.

> https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01

Good.

> defined carefully. If that’s done right, it can be used to support QKD-generated keys, or a daily or weekly courier.

Yes.

> generated significant controversy.

I think those should not be in the document itself. It could be in a
separate document.

> I *don’t* think it’s yet appropriate to work on one-time pad, as I think that results in more complex changes to IPsec than is reasonable to bite off.

But onetime pads is how implementations without access to quantum
computers would want to test their implementation.

Paul

---

From: Rodney Van Meter <[email-masked]>
Date: Thu, 30 Jun 2016 19:41:18 +0900

> On Jun 30, 2016, at 6:17 PM, Paul Wouters <[email-masked]> wrote:
> 

Sounds like agreement that we should work on _something_.

> I think those should not be in the document itself. It could be in a

Could be.

> computers would want to test their implementation.

Not sure we’re talking about the same thing here, might be that I’m sloppy in writing or reading.

Our I-D and Fluhrer both are talking about changes to IKEv2. I’m happy to see a one-time-use stream of such key material; that’s effectively our goal with any OOB keying mechanism. I’m not in favor of attempting to change the IPsec bulk data encryption protocol to use these OOB keys as a OTP. I think it’s too much to standardize, implement and test. Of course, I’m not the one who will be doing the bulk of the work, so if there’s somebody willing to take it on, I won’t stand in their way. It certainly is a useful long-term goal for the evolution of they keying, IMO.

		—Rod