YANG Data Model for Key Chains
RFC 8177

Note: This ballot was opened for revision 20 and is now closed.

(Alia Atlas) Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2017-04-24 for -20)
No email
send info
Just a couple of editorial comments:

-2.2: "This MAY be accomplished by accepting all the keys that have a valid accept lifetime and sending the key with the most recent send lifetime."
As written, that MAY sounds like a statement of fact rather than a normative requirement. If it's intended as normative, please consider restating in terms of actual procedure (e.g. "The receiver MAY accept ...")

-3, first paragraph: "Is a "key chain key" a key in the keychain, or something else? (maybe a key _for_ the keychain)?

(Benoît Claise) No Objection

Comment (2017-04-26 for -20)
No email
send info
Editorial:

- To be aligned with the other feature descriptions:
OLD:

  feature accept-tolerance {
       description
         "To specify the tolerance or acceptance limit.";
     }

NEW:

  feature accept-tolerance {
       description
         "Support the tolerance or acceptance limit.";
     }

- I would spell out "Network Management Datastore Architecture" [NMDA]

All lights are green from a tooling point of view.
As a side note, since you used the new NMDA tree structure, I would warn all the draft authors with YANG modules that depend on this YANG module that they might have to update their modules. See     https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-key-chain&recurse=0&rfcs=0 for the source of information.

Alissa Cooper No Objection

Comment (2017-04-26 for -20)
No email
send info
Matt raised some questions and comments in his Gen-ART review that the authors are engaging with: https://datatracker.ietf.org/doc/review-ietf-rtgwg-yang-key-chain-17-genart-lc-miller-2017-04-07/

Thanks!

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2017-04-24 for -20)
No email
send info
I had a few minor comments, mainly on the explanatory text -- I'm not a YANG expert (that's Benoit's job :-)):

1: "A key chain can be used by any service or application requiring authentication or encryption." - from my reading, this only symmetric keys; should this be "A key chain can be used by any service or application requiring authentication or encryption using symmetric keys"? 

2: "They are also used to support of security requirements (e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by vendors or only a single vendor." -- if it is not implemented, why put a key string on a device? Perhaps this was intended to be "not **yet** implemented..." ?

(Mirja Kühlewind) No Objection

Comment (2017-04-24 for -20)
No email
send info
Fully editorial comment: 
section 1 is just a copy of the abstract… this could be removed and section 2 could be used as section 1/intro (with sections 1.1, 1.2, and 2.1 as subsections; and section 2.2. could become the new section 2)

(Terry Manderson) No Objection

(Alexey Melnikov) (was Discuss) No Objection

Comment (2017-05-03)
No email
send info
Thank you for addressing my DISCUSS.

Maybe it is just me, but it would have helped to say that "key string in ASCII" is a passphrase. I was not sure whether "key string" was a term used in Routing and/or YANG circles. The best place to clarify this is in Section 2   (Problem Statement)

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2017-05-03)
No email
send info
Thank you for working through the SecDir review and making the suggested updates.

(Eric Rescorla) No Objection

Alvaro Retana No Objection

(Adam Roach) No Objection

Comment (2017-04-25 for -20)
No email
send info
- 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.

- 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.

- 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".

- 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.

- Copyright notice in the YANG file is 2015. Is that intentional?

- 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".

- 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.

- 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.

- 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.

 - 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?