Paul Hoffman <[email protected]> wrote: > If you agree with the need to standardize this usage, and believe that > draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting > place for that standardization, and are willing to review and > contribute text to the document if it is adopted by the WG, please say > so on the list. This WG has a history of adopting documents but then > not having enough reviewers for us to feel confident that we are making > a good standard, so we need to see a reasonable number of actively > interested people before we adopt the document. If it is not adopted, > the authors can ask for it to be published as an RFC through individual > submission or by the Independent Submissions Editor.
I think ISE is the right way. My comments start with the first paragraph: This document describes modifications to IKEv2 to use keys created via QKD for the Internet Key Exchange IKE_SA[RFC4306], the key agreement protocol for IPsec[RFC4301] . With the exception of the use of the new Payloads defined below and the removal of the Diffie- Hellman key agreement information, IKEv2 system operates in standard fashion. It seems like if one is going to use the QKD to distribute keys for other than direct use by IPsec, then the major reason for doing this is to get PFS. As such, why remove the DH? It seems like the QKD should just provide a PSK-like authentication. Some of the explanation seems to be: However, existing IPsec/IKE implementations actually have a lower data secrecy lifetime, due to their dependence on Diffie-Hellman key agreement. The security of Diffie-Hellman depends on the difficulty of the factoring problem, which remains uncertain; factoring may prove vulnerable either to theoretical advances in algorithms, or the deployment of large-scale quantum computers. An eavesdropper who records encrypted packets today can store those packets, and decrypt them later by discovering the key, when it becomes technically feasible to do so. I'm not entirely sure I understand how to QKD key material gets mixed in with the nonces, etc. to form keys; but that's probably because I read too quickly. I vote for ISE. Give them whatever numbers they need, and let's hear back how it goes... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [
pgpDBYgvW1tkp.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
