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

[Paul Wouters <[e-mail]>]

Looks good, thanks.

I guess the cert name is an arbitrary string than to reference the certificate by?

Paul

Sent using a virtual keyboard on a phone

> On Feb 2, 2024, at 11:46, Kent Watsen <[e-mail]> wrote:
> 
> 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
> 
>