Subject: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 25 Apr 2017 14:27:40 -0700

Adam Roach has entered the following ballot position for
draft-ietf-rtgwg-yang-key-chain-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 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.

- 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.

- 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".

- The second paragraph of section 3 is a bit non-obvious on first reading
-- consider spelling out that one chain has a valid send key but invalid
receive key, and vice-versa.

- Copyright notice in the YANG file is 2015. Is that intentional?

- On page 11, in "grouping lifetime", "case start-end-time", "choice
end-time", "case infinite", "description", replace "end-time in infinite"
with "end-time is infinite".

- On page 14, there's a assertion that hex allows specification of
"greater entropy with the same number of octets." It might be worth
qualifying this as *stored* octets, since it's demonstrably more octets
on the wire.

- Section 5 discusses the use of a KEK, distributed out-of-band, to
decrypt the keys stored in this format. There appears to be no affordance
for indicating the identity of which KEK to use, which would come in
handy for the types of key rotation schemes I'm familiar with. Mostly,
I'm worried about the "try it and see if it works" approach when you have
two valid KEKs (as during a transition), as it's not clear that you will
be able to distinguish success from failure in all cases.

- 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.

 - The IANA considerations section gives the YANG module prefix as
"ietf-key-chain". The YANG module itself defines the prefix as
"key-chain". I assume these should match each other?

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 25 Apr 2017 22:22:47 +0000

Hi Adam, 

>https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/

Agreed. Maybe this will partially satisfy Mirja’s request that I remove
the “Introduction" as well.
>I kept referring back to it), consider moving it down into section 3

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.
>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”.
>receive key, and vice-versa.

Ok. 
>- Copyright notice in the YANG file is 2015. Is that intentional?

Will update. 
>with "end-time is infinite".

Good catch. Will update.
>qualifying this as *stored* octets, since it's demonstrably more octets

Right - will add “internal key-string” to the assertion.
>be able to distinguish success from failure in all cases.

AES is an algorithm. I know there are 128, 192, and 256 bit varieties. Do
you want me to specify than any variety may be used? I almost removed this
out-of-band key encryption once.
>security without providing any real benefit. That mis-impression seems

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.

>"key-chain". I assume these should match each other?

Yes. Good catch, the IANA considerations section is wrong. I think have
enough comments now to constitute an update.

Thanks,
Acee

---

From: Adam Roach <[email-masked]>
Date: Tue, 25 Apr 2017 17:44:47 -0500

> out-of-band key encryption once.

This isn't about crypto-agility; it's about key rotation. This section 
posits a system in which you have some KEK, distributed out-of-band. 
Let's call the key we're using at this moment "Generation A." At some 
point -- let's say next week -- we decide that it's time to change the 
KEK to one we're going to call "Generation B." First, we need to get the 
"Generation B" KEKs to everyone before the switch-over (to avoid a 
period of time during which they can't decrypt the YANG-stored keys). 
The issue becomes: once you have both "Generation A" and "Generation B", 
how do you know which one to use to decrypt the YANG keys? If there were 
a place to store a key ID in the YANG model, it could identify which of 
the two keys to use. Lacking that, for some kinds of data, you can do a 
"try both and see which works," but it's not clear that doing so is 
possible in this case (since the thing you're decrypting is a key, and 
will simply look like random bits regardless of which KEK you use on it, 
you can't examine its structure to determine whether it is valid).

This isn't a blocking comment; I'm just wondering whether this 
operational aspect occurred to the WG when this scheme was being 
discussed, and whether there's some trivial way to perform KEK rotation 
that could be described in the document. Without the ability to rotate 
the KEK, I'm not sure this scheme is all that useful.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 25 Apr 2017 17:51:27 -0500

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

> the “Introduction" as well.

Sounds good to me.

> 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.

> 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]

> “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.

/a

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Apr 2017 16:29:21 -0700

On Tue, Apr 25, 2017 at 3:51 PM, Adam Roach <[email-masked]> wrote:

> to turn into a larger conversation. Answering the remaining points in this
> email. Thanks for being so responsive!
>
> /a
>
> Consistency with other YANG documents seems reasonable motivation to keep
> this as-is.
>
> can't use "always" if this scheme is in use (unless you want to resolve it
> some other way).
>
>
> 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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Apr 2017 00:47:29 +0000

>the KEK, I'm not sure this scheme is all that useful.

It seems that this should have been covered in some other Security RFC. If
not RFC 5649 (which seems to be inexplicably narrow in scope), then some
other Security document. If there is am out-of-band KEK procedure for
encryption of key string, then it should have been documented prior to my
usage. I’m copying Brian Weis (a Security Directorate member) who
originally suggested this. My inclination is to remove all traces of AEA
Key Wrap (RFC 5649) and rely on NCACM.

Thanks, 
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Apr 2017 00:54:22 +0000

Hi Adam, 

>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.

>can't use "always" if this scheme is in use (unless you want to resolve

Right - will do. Other approaches are possible but this is the one I
implemented at Redback/Ericsson with success.

>area thinking around this is." I'd be curious to have EKR or Kathleen

I’d be interested as well since adding this wasn’t something I was sure
added value in the first place.

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Apr 2017 01:03:14 +0000

Hi Eric,

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 25, 2017 at 7:29 PM
To: Adam Roach <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT)

On Tue, Apr 25, 2017 at 3:51 PM, Adam Roach <[email-masked]<mailto:[email-masked]>> 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, 5:27 PM, "Adam Roach" <[email-masked]<mailto:[email-masked]>> wrote:

Sounds good to me.

Consistency with other YANG documents seems reasonable motivation to keep this as-is.

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; 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?

I don’t broach the subject of display here – this is with respect to the internal storage of the keys.

Are you talking about the NETCONF <get-config> operation [RFC 6241] on the YANG model? If you have the proper NCACM permissions, then you will be able to retrieve the key strings in plain text.

Thanks,
Acee

-Ekr

/a

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Wed, 26 Apr 2017 15:45:00 +0000

Distributing and maintaining keys has a higher security bar than most configuration items, because their leakage can usually cause more harm. For example, a leaked key from the routing key chain could allow an attacker to substitute its own routing messages for authentic ones.

Distributing plain-text keys through a general purpose configuration protocol is not always considered safe. When the configuration  protocol is protected (e.g., TLS), the security requirements of some users are satisfied because they are only worried about protecting the keys on the wire.  But other users with larger threat profile (e.g., government users) often do not consider sending plain-text keys through a protected configuration protocol to be sufficient, because they may not have enough control over the ciphers chosen for the TLS session, or perhaps they want to protect the keys in the configuration system before they are delivered to the TLS session. In these cases it’s valuable to "key wrap” (encrypt) the keys in the software that generates the keys, and unwrap them in the piece of software that is actually installing the keys. That’s the motivation for including an optional key wrap method in the key chain Yang data model.

Yes, using a key wrap method means there’s an extra complication with  needing to maintain a key wrap key. Users that require the use of a key wrap probably don’t have a problem with distributing a key out of band for this. Distributing it in-band would likely mean sending it through a different Yang data model, which would have exactly the same problem of needing to be key wrapped so I’m not sure it’s valuable to even specify an in-band method. If that’s a hard requirement, then I suppose the key wrap method can be removed. But the removal of the key wrap option  is likely to restrict the users who can use the key chain data mode.

Hope that helps,
Brian

> On Apr 25, 2017, at 5:47 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> 

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Apr 2017 15:55:17 +0000

Hi Brian, 

On 4/26/17, 11:45 AM, "Brian Weis (bew)" <[email-masked]> wrote:

>Distributing and maintaining keys has a higher security bar than most
>configuration items, because their leakage can usually cause more harm.
>For example, a leaked key from the routing key chain could allow an
>attacker to substitute its own routing messages for authentic ones.
>
>Distributing plain-text keys through a general purpose configuration
>protocol is not always considered safe. When the configuration  protocol
>is protected (e.g., TLS), the security requirements of some users are
>satisfied because they are only worried about protecting the keys on the
>wire.  But other users with larger threat profile (e.g., government
>users) often do not consider sending plain-text keys through a protected
>configuration protocol to be sufficient, because they may not have enough
>control over the ciphers chosen for the TLS session, or perhaps they want
>to protect the keys in the configuration system before they are delivered
>to the TLS session. In these cases it’s valuable to "key wrap” (encrypt)
>the keys in the software that generates the keys, and unwrap them in the
>piece of software that is actually installing the keys. That’s the
>motivation for including an optional key wrap method in the key chain
>Yang data model.
>
>Yes, using a key wrap method means there’s an extra complication with
>needing to maintain a key wrap key. Users that require the use of a key
>wrap probably don’t have a problem with distributing a key out of band
>for this. Distributing it in-band would likely mean sending it through a
>different Yang data model, which would have exactly the same problem of
>needing to be key wrapped so I’m not sure it’s valuable to even specify
>an in-band method. If that’s a hard requirement, then I suppose the key
>wrap method can be removed. But the removal of the key wrap option  is
>likely to restrict the users who can use the key chain data mode.

Since RFC 5649 is simply the algorithm without much guidance on
operations, the inclusion of this option has raised more questions than
the commensurate benefit. Additionally, there is nothing precluding a user
from deploying KEK for the keys in the YANG key-chain model.

Finally, do you know of any implementations of KEK?

Thanks,
Acee

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Wed, 26 Apr 2017 16:04:59 +0000

Hi Acee,

On Apr 26, 2017, at 8:55 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,

On 4/26/17, 11:45 AM, "Brian Weis (bew)" <[email-masked]<mailto:[email-masked]>> wrote:

If you took out the key wrap method, then stating how a user might do the key wrapping themselves should be described in the draft. I guess that makes them responsible for pre- and post- processing of the keys in an implementation-specific manner..

Not with this data model, because I’m not involved with implementations of the data model. The use of a key wrap and KEK is used in other cases.

Brian

Thanks,
Acee

Hope that helps,
Brian

On Apr 25, 2017, at 5:47 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

On 4/25/17, 6:44 PM, "Adam Roach" <[email-masked]<mailto:[email-masked]>> wrote:

- Section 5 discusses the use of a KEK, distributed out-of-band, to
decrypt the keys stored in this format. There appears to be no
affordance
for indicating the identity of which KEK to use, which would come in
handy for the types of key rotation schemes I'm familiar with.
Mostly,
I'm worried about the "try it and see if it works" approach when you
have
two valid KEKs (as during a transition), as it's not clear that you
will
be able to distinguish success from failure in all cases.
AES is an algorithm. I know there are 128, 192, and 256 bit varieties.
Do
you want me to specify than any variety may be used? I almost removed
this
out-of-band key encryption once.

This isn't about crypto-agility; it's about key rotation. This section
posits a system in which you have some KEK, distributed out-of-band.
Let's call the key we're using at this moment "Generation A." At some
point -- let's say next week -- we decide that it's time to change the
KEK to one we're going to call "Generation B." First, we need to get
the
"Generation B" KEKs to everyone before the switch-over (to avoid a
period of time during which they can't decrypt the YANG-stored keys).
The issue becomes: once you have both "Generation A" and "Generation
B",
how do you know which one to use to decrypt the YANG keys? If there
were
a place to store a key ID in the YANG model, it could identify which of
the two keys to use. Lacking that, for some kinds of data, you can do a
"try both and see which works," but it's not clear that doing so is
possible in this case (since the thing you're decrypting is a key, and
will simply look like random bits regardless of which KEK you use on
it,
you can't examine its structure to determine whether it is valid).

It seems that this should have been covered in some other Security RFC.
If
not RFC 5649 (which seems to be inexplicably narrow in scope), then some
other Security document. If there is am out-of-band KEK procedure for
encryption of key string, then it should have been documented prior to
my
usage. I’m copying Brian Weis (a Security Directorate member) who
originally suggested this. My inclination is to remove all traces of AEA
Key Wrap (RFC 5649) and rely on NCACM.

Thanks,
Acee

/a

--
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]<mailto:[email-masked]>

--
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]<mailto:[email-masked]>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Apr 2017 12:05:13 -0400

Thanks, Brian for chiming in, I am just finishing my read of this
draft and looking at the NACM & referenced RFC5649.

> from deploying KEK for the keys in the YANG key-chain model.

I'd like to see this option stay as having better options to protect
keys is important.  Having said that, I agree that there isn't enough
guidance for the implementer and it would be good to add add that into
this draft.  I can put a discuss placeholder while we wait for that
text.

> Finally, do you know of any implementations of KEK?

This would be very helpful to know as well and if adding the guidance
to implement will increase the likelihood.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Apr 2017 12:08:14 -0400

On Wed, Apr 26, 2017 at 12:04 PM, Brian Weis (bew) <[email-masked]> wrote:
> Hi Acee,
>
> On Apr 26, 2017, at 8:55 AM, Acee Lindem (acee) <[email-masked]> wrote:
>
> Hi Brian,
>
> If you took out the key wrap method, then stating how a user might do the
> key wrapping themselves should be described in the draft. I guess that makes
> them responsible for pre- and post- processing of the keys in an
> implementation-specific manner..
>
>
> Not with this data model, because I’m not involved with implementations of
> the data model. The use of a key wrap and KEK is used in other cases.

Great, is this already documented in a draft or RFC for usage with
YANG data models?  If so, a reference to that would help or additional
text in this draft.  Having the guidance in one document to reference
would be helpful in any case (might be this one, I suspect).

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Apr 2017 11:24:16 -0500

I'm not concerned about how the KEKs get distributed.

I'm concerned about how you know which one to use.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Apr 2017 11:36:21 -0500

Okay, on further digging through RFC5649, it does have handling for this 
in the form of a 64-bit key data integrity check. So it looks like the 
"try it and see if it works" approach will be fine.

/a

On 4/26/17 11:24, Adam Roach wrote:
>> configuration items, because their leakage can usually cause more 
>> harm. For example, a leaked key from the routing key chain could 
>> allow an attacker to substitute its own routing messages for 
>> authentic ones.
>>
>> protocol is not always considered safe. When the configuration  
>> protocol is protected (e.g., TLS), the security requirements of some 
>> users are satisfied because they are only worried about protecting 
>> the keys on the wire.  But other users with larger threat profile 
>> (e.g., government users) often do not consider sending plain-text 
>> keys through a protected configuration protocol to be sufficient, 
>> because they may not have enough control over the ciphers chosen for 
>> the TLS session, or perhaps they want to protect the keys in the 
>> configuration system before they are delivered to the TLS session. In 
>> these cases it’s valuable to "key wrap” (encrypt) the keys in the 
>> software that generates the keys, and unwrap them in the piece of 
>> software that is actually installing the keys. That’s the motivation 
>> for including an optional key wrap method in the key chain Yang data 
>> model.
>>
>> Yes, using a key wrap method means there’s an extra complication 
>> with  needing to maintain a key wrap key. Users that require the use 
>> of a key wrap probably don’t have a problem with distributing a key 
>> out of band for this. Distributing it in-band would likely mean 
>> sending it through a different Yang data model, which would have 
>> exactly the same problem of needing to be key wrapped so I’m not sure 
>> it’s valuable to even specify an in-band method. If that’s a hard 
>> requirement, then I suppose the key wrap method can be removed. But 
>> the removal of the key wrap option  is likely to restrict the users 
>> who can use the key chain data mode.
>>
>> Hope that helps,
>> Brian
>>

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Apr 2017 11:46:07 -0500

On 4/25/17 18:29, Eric Rescorla wrote:
>     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
>
>

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.

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.

/a

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Apr 2017 17:03:09 +0000

From: Adam Roach <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 26, 2017 at 12:46 PM
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT)

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.

Thanks,
Acee

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Apr 2017 12:51:02 -0500

On 4/26/17 12:03, Acee Lindem (acee) wrote:
>
>
> From: Adam Roach <[email-masked] <mailto:[email-masked]>>
> To: Eric Rescorla <[email-masked] <mailto:[email-masked]>>
> Cc: Acee Lindem <[email-masked] <mailto:[email-masked]>>, The IESG 
> <[email-masked] <mailto:[email-masked]>>, Jeff Tantsura 
> <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] 
> <mailto:[email-masked]>" 
> <[email-masked] 
> <mailto:[email-masked]>>, Routing WG 
> <[email-masked] <mailto:[email-masked]>>
> Subject: Re: Adam Roach's No Objection on 
> draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT)
>
>>         security area thinking around this is." I'd be curious to
>>         have EKR or Kathleen weigh in
>>
>>
>     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.
>
>
>     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.
>
>

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.

/a

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Apr 2017 13:57:00 -0400

On Wed, Apr 26, 2017 at 1:51 PM, Adam Roach <[email-masked]> wrote:
> From: Adam Roach <[email-masked]>
> To: Eric Rescorla <[email-masked]>
> Cc: Acee Lindem <[email-masked]>, The IESG <[email-masked]>, Jeff Tantsura
> <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]"
> <[email-masked]>, Routing WG <[email-masked]>
> 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.
>
>
> 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.

-- 

Best regards,
Kathleen

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Apr 2017 13:07:04 -0500

> 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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Apr 2017 18:12:12 +0000

On 4/26/17, 1:57 PM, "Kathleen Moriarty"
<[email-masked]> wrote:

>>>area
>>storage
>>it's

This is not true for any IETF YANG models.

Thanks,
Acee