Hi Adam, On 4/25/17, 6:51 PM, "Adam Roach" <[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! Agreed. I added this RFC 5649 mechanism prior to using NCACM so, if it wrought with specification issues, then I’m inclined to remove it. > >/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). Right - will do. Other approaches are possible but this is the one I implemented at Redback/Ericsson with success. > > >[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. I’d be interested as well since adding this wasn’t something I was sure added value in the first place. Thanks, Acee > >/a _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
