> On Dec 7, 2014, at 8:48 AM, Tony Putman <[email protected]> wrote:
>
> Hi,
>
> I'm in favour of standardizing this work and am willing to review the
> document(s). I don't have a view on the best way to achieve this, but I think
> that the work would benefit from discussion on the list. There are a number
> of open questions in my mind, including the following:
> - Should this be QKD only, or PFS through generic OTP?
Keep in mind that at this point we are only modifying IKE’s process of
generating keys. The bulk encryption is still dependent on AES or whatever
algorithm you negotiate. However, OTP keys with short lifetimes is a good
balance between aggregate data rate and the rate of consumption of key
material, and is an excellent analogue for how QKD-generated keys should be
thought of, IMO.
> - Should this use PAK-DH? (there is a stronger argument for it if this is
> about a generic solution)
Open to advice here. If I understand what you’re suggesting, I think not.
> - Should there be a standardized structure to the Key ID? (Again, not needed
> for direct QKD)
I think the best suggestion on the table here is to *not* standardize that, but
to include an annex or appendix in the RFC describing use cases, of which the
first would be how we use them in QKD. This allows for different ideas of
generation, including whether or not you need to name the node, interface, even
port as the context in which a numeric key ID is to be interpreted. That would
be very different for couriered OTP, where it’s probably “pouch number”+”offset
inside pouch”.
> - What is the best way to derive the keying material?
Tero and a couple of others had opinions here.
—Rod
>
> Tony
>
> On 02/12/14 22:49, Rodney Van Meter wrote:
>> Hi,
>>
>> Sorry to be a little slow to reply. I was offline over Thanksgiving, just
>> saw the messages yesterday afternoon.
>>
>> Of course I favor adoption, and am willing to work with anyone who can
>> contribute to the development of an appropriate protocol. Momentum seems to
>> be toward a version supporting a variety of out-of-band mechanisms, and I’m
>> willing to work in that direction.
>>
>> Shota is looking in to the numerous issues I detailed in the long message
>> right after IETF.
>>
>> —Rod
>>
>>> On Dec 2, 2014, at 4:19 PM, Yaron Sheffer <[email protected]>
>>> <mailto:[email protected]> wrote:
>>>
>>> Here's a quick reminder to speak up if you're interested in this document
>>> and are willing to contribute as co-author or reviewer.
>>>
>>> Thanks,
>>> Yaron
>>>
>>> On 11/25/2014 10:06 PM, Paul Hoffman wrote:
>>>> <chair hats on>
>>>>
>>>> Greetings again. There is a small emerging industry of crypto solutions
>>>> that transmit keys using Quantum Key Distribution (QKD), and then use
>>>> those keys for classical high-speed encryption. Several such solutions are
>>>> using IKE, and there is a perceived need to standardize this usage. If so,
>>>> that standardization should be done in this Working Group.
>>>>
>>>> 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.
>>>>
>>>> Please reply by December 8, 2015.
>>>>
>>>> --Paul Hoffman and Yaron Sheffer
>>>> _______________________________________________
>>>> IPsec mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>> <https://www.ietf.org/mailman/listinfo/ipsec>
>>>>
>>> _______________________________________________
>>> IPsec mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>> <https://www.ietf.org/mailman/listinfo/ipsec>
>> _______________________________________________
>> IPsec mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/ipsec
>> <https://www.ietf.org/mailman/listinfo/ipsec>
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
