Re: [netconf] Paul Wouters' Discuss on draft-ietf-netconf-keystore-30: (with DISCUSS)

[Kent Watsen <[e-mail]>]

Hi Paul,

Thank you for your review.
Please find responses below.

Kent

> On Jan 31, 2024, at 9:58 PM, Paul Wouters via Datatracker <[e-mail]> wrote:
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-netconf-keystore-30: Discuss
> 
> 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/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I support Roman's discuss with respect to the backup/restore procedure. Perhaps
> limit it to say that a global KEK could be used to facilitate this, but not go
> into details on how this would work with diagrams?

I’m hoping that my response to Roman was convincing.  

I think that this section can be fixed by adding text to provide any clarifications needed.


> Similar to draft-ietf-yang-crypto-types:
> 
>     |     +--rw certificates
>     |     |  +--rw certificate* [name]
>     |     |     +--rw name                      string
> 
> Certificate identity is either done by entire DN, The Common Name (CN) RDN,
> or by a list of subjectAltName (SAN) entries. Can the latter be expressed
> here? Should a type be introduced? ("CN", "DN", "SAN") ? Should the type be
> a list as 1 certificate can have multiple identities via multiple SAN entries.
> 
> See also:
> 
>     +--rw end-entity-cert-with-key* [name]
>        +--rw name
>        |       string

The same comment was made by Éric.  

I’m trying to not require the “name” be any particular value found in a cert.

The documentation could suggest cert-values as good candidates, but maybe that’s too obvious?


> Section 4.1:
> 
>        A server MUST possess (or be able to possess, in case the KEK has
>        been encrypted by yet another KEK) a KEK's cleartext value so that
>        it can decrypt the other keys in the configuration at runtime.
> 
> Perhaps "MUST possess access to KEK or API using the KEK"? A server might
> be using a TEE and not really have the KEK itself, but it can send a decryption
> job to an API inside the TEE that could use the KEK and return the decrypted
> key. In this case, the server does sort of "possess" the key but never its
> "cleartext value".

Completely agree - great suggestion!

OLD:
-          <t>A server MUST possess (or be able to possess, in case the KEK has
-            been encrypted by yet another KEK) a KEK's cleartext value so that it
-            can decrypt the other keys in the configuration at runtime.</t>

NEW:
+          <t>A server MUST possess access to the KEK or an API using the KEK,
+            so that it can decrypt the other keys in the configuration at runtime.</t>



> Section 4.2:
> 
>        Implementations SHOULD provide an API that simultaneously generates and
>        encrypts a key (symmetric or asymmetric) using a KEK.
> 
> Should that say "(symmetric or private asymmetric)" ?

It could, but I found the result more confusing.  e.g., do we refer to the generated-key or the KEK that may be symmetric or asymmetric?  I found that removing that text allowed for a better flow without losing much;  that any kind of key can be encrypted by any other kind of key is defined in the YANG module.  So this is what I came up with:

OLD:
           <t>Implementations SHOULD provide an API that simultaneously generates
-            and encrypts a key (symmetric or asymmetric) using a KEK.  Thus the
             cleartext value of the newly generated key may never be known to the
             administrators generating the keys.</t>

NEW
           <t>Implementations SHOULD provide an API that simultaneously generates
+            a key and encrypts the generated key using a KEK.  Thus the
             cleartext value of the newly generated key may never be known to the
             administrators generating the keys.</t>

Good?


> Section 5.1:
> 
>        In order to satisfy the expectations of a "keystore", it
>        is RECOMMENDED that implementations ensure that the keystore
>        contents are encrypted when persisted to non-volatile memory.
> 
> I would probably add "and ensure keystore contents that have been decrypted in
> volatile memory are zeroized when not in use".

Hmmm, but the section title is "Security of Data at Rest”…

Okay, I changed the title to “Security of Data at Rest and in Motion”.
I also added your text, and dropped the middle paragraph.

The diff is convoluted, but the final result is this:

       <section title="Security of Data at Rest and in Motion">
           <t>The YANG module defined in this document defines a mechanism called a
             "keystore" that intends to protect its contents from unauthorized
             disclosure and modification.</t>
           <t>In order to satisfy the expectations of a "keystore", it
             is RECOMMENDED that implementations ensure that the keystore
             contents are encrypted when persisted to non-volatile memory,
             and ensure that the keystore contents that have been decrypted
             in volatile memory are zeroized when not in use.</t>
       </section>

Fixed?

FYI, zeroisation is also discussed in the "crypto-types" draft here:
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-29#section-3.9


Thanks again,
Kent