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]> 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.
/a
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
