On 4/26/17 12:57 PM, Kathleen Moriarty 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.
Excellent, thanks!
That's a comment for the other thread, though, where the keys are
distributed as ciphertext, using KEKs shared between multiple network
elements.
*This* thread is about is about distributing the keys in plaintext
(modulo any transport security applied), and then storing them
obfuscated as a matter of local policy, using keys and/or algorithms
completely local to the single network element. I would love for you to
weigh in on the wisdom of doing so.
/a
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
