Re: [netconf] I-D Action: draft-ietf-netconf-keystore-27.txt

[tom petch <[e-mail]>]

From: Henk Birkholz <[e-mail]>
Sent: 18 January 2023 12:56

Hi Tom,

to your comment on "Security 101" content. I do not see that basic
repetition as a flaw considering the scope of audience, as implementers
might occasionally tend not to read all useful, but only the minimal
essential documents.

Having said that. Maybe the "Security 101" problem can be avoided by
some well-selected references to the extend of "Security Considerations
about key management of RFC-XXXX apply"? That could avoid the repetition
a bit.

<tp>
Henk

I am contrasting this I-D with RFC8177 on key chains which says
'  Implementations with keys provided via this model should store them
   using best current security practices.'
which is the sort of statement I would expect to see in a routing or ops RFC, leaving the technical detail to a Security Area one!

Tom Petch

 

Viele Grüße,

Henk

On 18.01.23 13:37, tom petch wrote:
> Some thoughts, editorial mostly, on this version of this I-D.
>
> Generally, I find many of the identifiers cumbersome, up to nine hyphen separated elements; I would see three or four as good and five as tolerable, more than that error prone,
>
>       grouping local-or-keystore-end-entity-cert-with-key-grouping
> As ever, I see -grouping as prolix.  I would also like to shorten local-or-keystore as a generic term for well, locality, or location, or place or site or   .... there are lots of possible synonyms.  Also where the grouping is about a cert then I think that that should come before locality.  To me it is the cert that matters not the option about its locality
>
> I would also like to shorten 'cert-with-key' which occurs many times but do not have an alternative to offer.
>
> The other general comment is that in places this reads as Security 101, which I do not think that the Netconf WG should be publishing (even if the text has come from Security ADs or such like).  The changes here would be small, deletions mostly,  but I think should be made.  Thus comments about built-in keys SHOULD NOT be cleartext are nothing to do with a YANG module, they are or they are not and no YANG module is going to change that.   There are several such statements in sections 3, 4 and 5 which to me belong in a BCP from the Security Area.
>
> Some less contentious points.
>
>       grouping asymmetric-key-pair-with-cert-grouping
>       grouping asymmetric-key-pair-with-certs-grouping
> I think an unfortunate pairing; that letter 's' buried in the middle will be missed.  Even
>       grouping asymmetric-key-pair-with-cert
>       grouping asymmetric-key-pair-with-certs
> could cause erors.
>
>     The term "keystore" is defined in this /draft /document/
>
> The term "key" may be used to mean one of three things in this /draft:/document/
> Well, four to be picky - you also have it from RFC2119
>
> In the tree diagrams. the type 'string' seems to wander around, as in 2.1.3.7, and not stay in a predictable place
>
> What happens to choice/case if no features are defined?  I do not know if YANG can enforce or cope with that.
>
> s.2.1.4
> 'The protocol-accessible nodes for the "ietf-keystore" module are an instance'
> perhaps instances
>
> s.2.2.3
>   a big section when there are no pages numbers - worth splitting into subsections IMHO
>
> prefix eku
> we could do with a documentation-only YANG prefix; to me this looks too real, perhaps ex-eku
>
> s.3
> built-in keys
> Built into what?  The YANG module?  suggest 'built into the device' or some such.
>
> I-D.ma-netmod-with-system
> needs to be Normative IMHO - I cannot understand system without it
>
> copied into <running>
> copied from where?
>
> all key types may be copied
> again, copied from where?
>
> built-in key
> lacks a terminal period
>
> <running> data tree
> Why data tree here when every else is just <running>?
>
> s.4 Nothing to do with Netconf IMHO!
>
> s.5.3
> SSH, TLS lack references
>
> Tom Petch
>
> _______________________________________
> From: netconf <[e-mail]> on behalf of [e-mail] <[e-mail]>
> Sent: 12 December 2022 18:49
> To: [e-mail]
> Cc: [e-mail]
> Subject: [netconf] I-D Action: draft-ietf-netconf-keystore-27.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network Configuration WG of the IETF.
>
>          Title           : A YANG Data Model for a Keystore
>          Author          : Kent Watsen
>    Filename        : draft-ietf-netconf-keystore-27.txt
>    Pages           : 52
>    Date            : 2022-12-12
>
> Abstract:
>     This document defines a YANG module called "ietf-keystore" that
>     enables centralized configuration of both symmetric and asymmetric
>     keys.  The secret value for both key types may be encrypted or
>     hidden.  Asymmetric keys may be associated with certificates.
>     Notifications are sent when certificates are about to expire.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-netconf-keystore-27.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-netconf-keystore-27
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
> ____________________________
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf