On Tue, Apr 25, 2017 at 3: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! > > /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 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? -Ekr > /a > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
