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

[Kent Watsen <[e-mail]>]

Hi Tom,

Thank you for your review of the keystore draft.
Please see below for my responses to your comments.

Kent



> On Jan 18, 2023, at 11:48 AM, tom petch <[e-mail]> wrote:
> 
> 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.

You're the first to bring this up.   Whilst you make good points, I'm unwilling to change names unless others chime in.

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

See discuss with Henk at top.   IDK about the the keychain draft, does it's data-model contain nodes such as "cleartext-password", "hidden-password", or "encrypted-password"?   The particular paragraph mentioned regards "built-in" keys, a concept unique to this draft (AFAIK), and it seems proper for the draft to say that "Built-in key types SHOULD be either hidden or encrypted", but not cleartext (even if projected by NACM).   FWIW, I think that there were two SecDir reviews on these sections.

WRT "There are several such statements in sections 3, 4 and 5", please provide a complete list.


>> 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 error you're concerned about seems like a small thing.  That is, even if the wrong name were entered, the tree-diagram or CLI/UI would quickly reveal.  So no a big deal?



>>    The term "keystore" is defined in this /draft /document/

Fixed - other instances (in this draft) are fixed as well.

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

Yeap, like this one.  Fixed.


>> In the tree diagrams. the type 'string' seems to wander around, as in 2.1.3.7, and not stay in a predictable place

The tree-diagrams are generated using the latest version of pyang.  The closest RFC 8340 comes to providing guidance is "Additional whitespace may, for example, be used to "column align" fields (e.g., within a list or container) to improve readability".   I don't think we can fault pyang (though we could wish for better).

In lieu of fixing the tool, I could manually edit the tree diagrams, but that is both a lot of work and error-prone.  Note that the tree-diagrams are automatically generated and inserted every time I `make` and the document.


>> What happens to choice/case if no features are defined?  I do not know if YANG can enforce or cope with that.

Where are you?   Regardless, all the "choice" statements in ietf-keystore are "mandatory true", meaning that one case must be defined.


>> s.2.1.4
>> 'The protocol-accessible nodes for the "ietf-keystore" module are an instance'
>> perhaps instances

Fixed.


>> s.2.2.3
>>  a big section when there are no pages numbers - worth splitting into subsections IMHO

Subsections added.


>> prefix eku
>> we could do with a documentation-only YANG prefix; to me this looks too real, perhaps ex-eku

Changed to "ex-keystore-usage"


>> s.3
>> built-in keys
>> Built into what?  The YANG module?  suggest 'built into the device' or some such.

Now: "keys built-in into the server".



>> I-D.ma-netmod-with-system
>> needs to be Normative IMHO - I cannot understand system without it

This document is not dependent on that work; it merely offered the reference as a related work.

That said, searching for "system", I found and replaced several instances to use the word "server" instead.  I think this may've been the actual source of your confusion.

Also, updated ref to point to adopted name: "ietf-netmod-system-config".


>> copied into <running>
>> copied from where?

Two paragraphs up: "...they are present in <operational> (and <system>, if used)."


>> all key types may be copied
>> again, copied from where?

Again,  <operational> (and <system>, if used).   This paragraph also says <operational> a sentence later"


>> built-in key
>> lacks a terminal period

Fixed.


>> <running> data tree
>> Why data tree here when every else is just <running>?

Removed.


>> s.4 Nothing to do with Netconf IMHO!

The WG or the protocol?

Regardless, this draft defines a data-model and related semantics.  You may not be aware, but many wanted to see this section fleshed out.


>> s.5.3
>> SSH, TLS lack references

You're right, but this is in the template published by the IESG.  There are likely several dozen RFCs published this way...


Kent



>> 
>> 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
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf