> On Jun 29, 2016, at 3:12 AM, Waltermire, David A. (Fed) > <[email protected]> wrote: > > 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?
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
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
