On 4/26/17, 1:57 PM, "Kathleen Moriarty" <[email protected]> wrote:
>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. This is not true for any IETF YANG models. Thanks, Acee > >Thanks. >> >> /a > > > >-- > >Best regards, >Kathleen _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
