OK, I admit my previous email was a bit short on detail :-) On 07/12/14 17:24, Rodney Van Meter wrote: >> - 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. > What I meant was that if we only consider a direct QKD link between the endpoints, then the keys are (theoretically) completely secure. But if we are considering other methods of sharing these keys, then there is an additional D-H barrier for an attacker to overcome if PAK-DH is used. Of course, there is also additional computation needed, so there is a trade-off. I think that it's worth discussing the trade-off on the list. >> - 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”. > I feel that the right thing to do here is to include a one-byte KEY_ID_TYPE, and at this stage to only define a single value (OPAQUE). This give scope to specialize it if necessary without needing any further changes to the protocol. It is difficult to know how this is going to be used, so I am in favour of keeping some flexibility (within reason, of course).
Tony _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
