Hi Eric, From: Eric Rescorla <[email protected]<mailto:[email protected]>> Date: Tuesday, April 25, 2017 at 7:29 PM To: Adam Roach <[email protected]<mailto:[email protected]>> Cc: Acee Lindem <[email protected]<mailto:[email protected]>>, The IESG <[email protected]<mailto:[email protected]>>, Jeff Tantsura <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Routing WG <[email protected]<mailto:[email protected]>> Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT)
On Tue, Apr 25, 2017 at 3:51 PM, Adam Roach <[email protected]<mailto:[email protected]>> wrote: I wanted to treat the KEK issue separately, since it has the possibility to turn into a larger conversation. Answering the remaining points in this email. Thanks for being so responsive! /a On 4/25/17 17:22, Acee Lindem (acee) wrote: Hi Adam, On 4/25/17, 5:27 PM, "Adam Roach" <[email protected]<mailto:[email protected]>> wrote: - The second paragraph in the Abstract seems very specific for an Abstract. Since this variation is covered in the Introduction, consider removing it from the Abstract. Agreed. Maybe this will partially satisfy Mirja’s request that I remove the “Introduction" as well. Sounds good to me. - Since the syntax in section 1.2 is used only in section 3.3 (from which I kept referring back to it), consider moving it down into section 3 somewhere. I’m hesitant to do this since all the other YANG documents have the tree syntax as a sub-section of the “Introduction”. Refer to RFC 7223. Consistency with other YANG documents seems reasonable motivation to keep this as-is. - Section 2.2 describes a scheme in which the key with the "most recent send lifetime" is used for sending. The data model allows for lifetimes to be indicated with "always." It seems that there should be treatment of the interaction between "most recent" and "always". If you use “always”, you’re graceful key roll-over won’t be very effective. Could I satisfy this by defining “most recent”? It is the key with the latest start-time”. I think that part is clear. What probably needs to be said is that you can't use "always" if this scheme is in use (unless you want to resolve it some other way). [several resolved points elided] - Section 5 also suggests keys be encrypted or obfuscated on the device that is to use them, presumably in a way that can be decrypted or unobfuscated using information also on the device. I don't know what the current security area thinking around this is, but given that the information needed to retrieve plaintext keys is necessarily present on the device, this seems like a fig-leaf that provides an illusion of security without providing any real benefit. That mis-impression seems potentially harmful. I only added this at the behest of one of the other reviews. The problem with security is that there conflicting opinions, and as the adage goes “everybody’s got one.” I’ll defer to the Security ADs. Right; that's what I meant by "I don't know what the current security area thinking around this is." I'd be curious to have EKR or Kathleen weigh in What I took home here was that you would encrypt them and display the encrypted version instead of showing asterisks. Is that not what the thinking was? I don’t broach the subject of display here – this is with respect to the internal storage of the keys. Are you talking about the NETCONF <get-config> operation [RFC 6241] on the YANG model? If you have the proper NCACM permissions, then you will be able to retrieve the key strings in plain text. Thanks, Acee -Ekr /a
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
