Hi Adam, On 4/25/17, 5:27 PM, "Adam Roach" <[email protected]> wrote:
>Adam Roach has entered the following ballot position for >draft-ietf-rtgwg-yang-key-chain-20: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >- 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. > >- 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. > >- 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”. > >- The second paragraph of section 3 is a bit non-obvious on first reading >-- consider spelling out that one chain has a valid send key but invalid >receive key, and vice-versa. Ok. > >- Copyright notice in the YANG file is 2015. Is that intentional? Will update. > >- On page 11, in "grouping lifetime", "case start-end-time", "choice >end-time", "case infinite", "description", replace "end-time in infinite" >with "end-time is infinite". Good catch. Will update. > >- On page 14, there's a assertion that hex allows specification of >"greater entropy with the same number of octets." It might be worth >qualifying this as *stored* octets, since it's demonstrably more octets >on the wire. Right - will add “internal key-string” to the assertion. > >- Section 5 discusses the use of a KEK, distributed out-of-band, to >decrypt the keys stored in this format. There appears to be no affordance >for indicating the identity of which KEK to use, which would come in >handy for the types of key rotation schemes I'm familiar with. Mostly, >I'm worried about the "try it and see if it works" approach when you have >two valid KEKs (as during a transition), as it's not clear that you will >be able to distinguish success from failure in all cases. AES is an algorithm. I know there are 128, 192, and 256 bit varieties. Do you want me to specify than any variety may be used? I almost removed this out-of-band key encryption once. > >- 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. > > - The IANA considerations section gives the YANG module prefix as >"ietf-key-chain". The YANG module itself defines the prefix as >"key-chain". I assume these should match each other? Yes. Good catch, the IANA considerations section is wrong. I think have enough comments now to constitute an update. Thanks, Acee > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
