On Wed, Apr 26, 2017 at 1:51 PM, Adam Roach <[email protected]> wrote: > On 4/26/17 12:03, Acee Lindem (acee) wrote: > > > > From: Adam Roach <[email protected]> > Date: Wednesday, April 26, 2017 at 12:46 PM > To: Eric Rescorla <[email protected]> > Cc: Acee Lindem <[email protected]>, The IESG <[email protected]>, Jeff Tantsura > <[email protected]>, "[email protected]" <[email protected]>, > "[email protected]" > <[email protected]>, Routing WG <[email protected]> > Subject: Re: Adam Roach's No Objection on > draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) > > On 4/25/17 18:29, Eric Rescorla wrote: > > > > On Tue, Apr 25, 2017 at 3:51 PM, Adam Roach <[email protected]> wrote: > >> >> >>>> - 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? > > > By my reading, this is just talking about encrypting "on the disk" storage > on the device. Any processes involved in provisioning the values or using > them to process traffic would have access to the plaintext, presumably by > reading the encrypted form off disk, reading some keying material off disk, > and combining them to retrieve the plaintext key. > > > This is the correct interpretation. > > > > My concern is: if these process can extract the plaintext key from > information stored on the disk, then so can other processes on the same > device. Encryption in this case seems to provide the mere illusion of > security -- akin to installing an deadbolt keyhole on a door that has no > actual bolt attached. > > > I don’t see any way around this if you want to use the keys. > > > So don't encrypt the keys on disk. To use the analogy I set up above -- it's > better for people to *know* that there's no deadbolt than to mistakenly > think that there is one: it leads them to take an appropriate level of > precaution.
Brian pointed out that RFC5649 is used with other YANG modules, so I'm going to poke at the gap a little that Acee mentioned for operators. Thanks. > > /a -- Best regards, Kathleen _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
