Re: [netconf] Document Shepherd Review of draft-ietf-netconf-keystore

[Kent Watsen <[e-mail]>]

Hi Qin,

> As part of WGLC process, I am assigned as document shepherd for draft-ietf-netconf-keystore.

Thank you for your valuable comments!

> Thank for your hard work on this document. Here is my review
> on the latest version of trust anchor work.

Please find my responses to your comments below, and see the just-posted updated draft..

Kent


> 1. Section 1
> What is Public half? Can you provide reference or defintion for public half.

I replaced "the public half" with "its public half", where "its" refers to "asymmetric key", to make it a bit clearer.

FWIW, In asymmetric cryptography, there is a key-pair (public and private), each of which can be being one half of a matching key-pair.   Makes sense?  


> 2. Section 1, last paragraph
> How keystore utilities or HSM is related to TPM?

Rewrote paragraph to:

          Implementations may utilize zero or more operating system level
          keystore utilities (e.g., "Keychain Access" on MacOS) and/or cryptographic
          hardware (e.g., TPMs).

To a) clarify "utilities" and b) align the text with the preceding paragraph.

FWIW, a TPM and HSM are nearly identical, the biggest difference being that the TPM is typically soldered onto a motherboard whereas an HSM is a removable device.  Both come under the category of "cryptographic hardware".


> Where keystore utilities or HSM is defined? Is this something relate to TEE （Trust Execution Environment）

See previous comment.


> 3. Section 1.1
> Do we need to add figure name for the figure depicted in section 1.1
> When we say this document presents one or more YANG modules…, I am wondering whether we present one module or multiple modules, or we want to emphasize this document defines only one YANG module, which is ietf-keystore?

Please see my response to your same comment on the "trust-anchors" draft.


> 4.Section 1.3 said:
> "
>    The term "key" may be used to mean one of three things in this draft:
>    1) the YANG-defined "asymmetric-key" or "symmetric-key" node defined
>    in this draft, 2) the raw key data possessed by the aforementioned
>    key nodes, and 3) the "key" of a YANG "list" statement.  This draft
>    attempts to always qualify types '2' and '3' using, "raw key value"
>    and "YANG list key" where needed.  In all other cases, an unqualified
>    "key" refers to a YANG-defined "asymmetric-key" or "symmetric-key"
>    node
>  
> "
> Thank for clarification for this, I am not clear how these three type keys are distinguished from each other? Based on the context?

There is context, for sure but, before, sometimes a paragraph would refer to an unqualified "key" and that was confusing folks.  Makes sense?


> 5. Section 2.1.3.3 said:
> "
>    *  A "choice" statement is used to expose the various options.  Each
>       option is enabled by a "feature" statement.
> "
> Use feature for each case under choice statement seems redundant to me

To clients, yes, but here the feature statement is used by the *server* to define which of the options exist.  These serve different purposes.  Makes sense?


> 
> 6. Section 2.1.3.5
> s/soley/solely
Fixed.


> 7. Section 2.1.3.6 said:
> "
> *  A "choice" statement is used to expose the various options.  Each
>       option is enabled by a "feature" statement.
> "
> Use feature for each case under choice statement seems redundant to me.

See above.


> 8. Section 4.1, paragraph 2 said:
> "
> If a KEK is a symmetric key, then the server MUST provide an API for
>    administrators to encrypt other keys without needing to know the
>    symmetric key's value. 
> "
> This sentence seems to contradict to the last paragraph in this section
> i.e.,
> "
> 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.
> "
> Server doesn't need to know symmetric key's value when encrypting other keys.
> but server need to know symmetric key's value or KEK's cleartext when decrypting other keys.
> I am not security expert, please double check this.

The first paragraph regards administrators (clients), the second paragraph regards server-implementation.  Note that the 2nd paragraph's use of the word "server" extends to any cryptographic hardware it may utilize. 


>  
> 9. Section 5.1
> Can you provide a reference to data in motion vs data at rest
> Is Data in motion related to migrating configuration to a second server in section 4.3？

I replaced "rest" with "data at rest (e.g., on disk)", so that it's clear in context.

FWIW, "motion" refers to "on the wire" movement, whereas "rest" refers to a persisted state.


>  
> 10. Section 5.3 said:
> "
>    The NACM
>    "default-deny-all" extension has not been set for any data nodes
>    defined in this module.
>  
>       |  Please be aware that this module uses the "cleartext-key" and
>       |  "cleartext-private-key" nodes from the "ietf-crypto-types"
>       |  module [I-D.ietf-netconf-crypto-types], where said nodes have
>       |  the NACM extension "default-deny-all" set, thus preventing
>       |  uncontrolled read-access to the cleartext key values.
>  
> "
> I am confused that whether NACM “default-deny-all” is used or not used in this document?
> When we say this module uses the "cleartext-key" and "cleartext-private-key" nodes from the "ietf-crypto-types"
> therefore "cleartext-key" and "cleartext-private-key" nodes has been inherited from other module and can also
> be seen as nodes in this module, no?

You are correct.  I changed the paragraph to read as follows, and removed the "aside":

   Some of the readable data nodes defined in this YANG module may be
   considered sensitive or vulnerable in some network environments.  It
   is thus important to control read access (e.g., via get, get-config,
   or notification) to these data nodes.  These are the subtrees and
   data nodes and their sensitivity/vulnerability:

   *  The "cleartext-key" node:

         The "cleartext-key" node, imported from the "symmetric-key-
         grouping" grouping defined in [I-D.ietf-netconf-crypto-types]
         is additionally sensitive to read operations such that, in
         normal use cases, it should never be returned to a client.  For
         this reason, the NACM extension "default-deny-all" was applied
         to it in [I-D.ietf-netconf-crypto-types].

   *  The "cleartext-private-key" node:

         The "cleartext-private-key" node defined in the "asymmetric-
         key-pair-grouping" grouping defined in
         [I-D.ietf-netconf-crypto-types] is additionally sensitive to
         read operations such that, in normal use cases, it should never
         be returned to a client.  For this reason, the NACM extension
         "default-deny-all" is applied to it in
         [I-D.ietf-netconf-crypto-types].

Thanks for catching this one!


Once everything settles, please update the Shepherd write-up posted to Datatracker to reflect an "all good" report (assuming that is true).

Thanks again,
Kent