Re: [netconf] AD review of draft-ietf-netconf-trust-anchors-20

[Kent Watsen <[e-mail]>]

Hi Rob,

> On Jun 23, 2023, at 6:35 AM, Rob Wilton (rwilton) <[e-mail]> wrote:
> 
> Hi Kent,
> 
> And replies to your comments on this draft as well are inline ...

Thank you.



> From: Kent Watsen <[e-mail]>
> Sent: 25 March 2023 16:41
> To: Rob Wilton (rwilton) <rwilton=[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [netconf] AD review of draft-ietf-netconf-trust-anchors-20
> 
> Hi Rob,
> 
> Thank you for your review!
> Please see below for comments.
> 
> Kent // author
> 
> 
> 
> 
> On Mar 22, 2023, at 5:51 AM, Rob Wilton (rwilton) <rwilton=[e-mail]<mailto:rwilton=[e-mail]>> wrote:
> 
> Hi Kent,
> 
> Here are my review comments for draft-ietf-netconf-trust-anchors.  This document is also well written, so I would like to thank you, the shepherd, and WG for a high-quality document.
> 
> As before, I have a few comments, but will note that I'm not a security expert and hence some of my questions/comments may be due to my security ignorance ...
> 
> I really think that the key question about copying the certificates into running, and also how that will play with system datastore.  Further details inline below, but I will also flag this as an email to Netmod.  Hopefully there will be some time to discuss this.

Regarding the key question.

Section 3 <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-21#section-3> says:

The primary characteristic of the built-in trust anchors is that they are provided by the server, as opposed to configuration. As such, they are present in <operational>, and <system> [I-D.ietf-netmod-system-config <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-01>], if implemented.

That is, I think that it is out-of-scope for this draft.  Whatever solution the system-config draft identifies (including if the WG decides to not support offline-validation, and therefore discards the need to copy system data into <running> entirely) is perfectly fine.   From an AD-review perspective, do you see a need to update to this draft in any way? 



As for “system-config” being discussed In NETMOD, the draft currently says (or will say) when system config is copied into <running>, only the “key” fields (i.e., a cert’s name) need to be copied.  If a software-update changes the value of a trust-anchor while leaving the trust-anchor’s name the same, the clients are blissfully unaware.

The guidance the system-config draft is providing (or will provide) is that only necessary nodes (keys, and nodes referenced by “must” or “when” expressions) need to be copied.  But that language does not preclude the client from copying *all* the nodes, in which case the cert-data *would* be copied  and, if updated via a software-upgrade, could be out of date.  

Two options:

1) The system-draft says non-necessary fields MUST NOT be copied into <running>.  This may be difficult to enforce, but I believe it’s viable.

2) The system-draft says that it is the server’s responsibility to migrate the data in running/startup/candidate during a software update.

Thoughts?  (Again noting that this convo should be on the NETMOD list)



> I agree with the sentiment.  Specifically, given the understanding:
>   * for <system> before YANG-next: nodes are always coped into <running>.
>   * for <system> after YANG-next: nodes are coped into <running> only when needed.
> 
> But maybe we can spin it towards the future, by assuming NMDA will be fully realized someday?
> 
>   Built-in bags of trust anchors and/or specific trust anchors, that
>   are referenced by configutation (e.g., a "leafref"), MUST be present
>   in a datastore in order for the datastore to be valid.  For instance,
>   built-in nodes originating in <system> (from
>   [I-D.ietf-netmod-system-config]) will (per [RFC8342]) implicitly
>   propogate to <intended>, ensuring references to them will be resolved
>   in <intended>.
> 
> Actually, given that the "system-config" draft is now adopted (it didn't even exist when that text was first written), this draft could more broadly replace "built-in" with "system-defined" (no need for another term, right?) and then delete the next three paragraphs (as the mechanics should be defined in the system-config draft):

> [Rob Wilton (rwilton)]
> Thinking about this over the last couple of days, I wonder if it is better just to say less, and only say (note fixed typo for 'configutation') :
> 
>   Built-in bags of trust anchors and/or specific trust anchors, that
>   are referenced by configuration (e.g., a "leafref"), MUST be present
>   in a datastore in order for the datastore to be valid.

Updated. This item is resolved.


> I think that this paragraph may also be worth keeping:
> 
>   Built-in bags and/or their trust anchors MAY be copied into other
>   parts of the configuration but, by doing so, they lose their
>   association to the built-in entries and any assurances afforded by
>   knowing they are/were built-in.
> 
> But then removing the other two paragraphs, as you suggest.
> 
> 
> ===START: these 3 paragraphs could be removed===
> 
> 
>   The built-in bags and/or their trust anchors MUST be copied into
>   <running> using the same "key" values if it is desired for the server
>   to maintain/update them (e.g., a software update may update a bag of
>   trusted public CA certificates used for TLS-client connections).
> 
>   Built-in bags and/or their trust anchors MAY be copied into other
>   parts of the configuration but, by doing so, they lose their
>   association to the built-in entries and any assurances afforded by
>   knowing they are/were built-in.
> 
>   The built-in bags and/or their trust anchors are immutable by
>   configuration operations.  Servers MUST ignore attempts to modify any
>   aspect of built-in bags and/or their trust anchors from <running>.
> 
> ===STOP: these 3 paragraphs could be removed===
> 
> 
> Thoughts?

Removed the other two paragraphs. This item is resolved.




>>> (2) p 28, sec 3.  Support for Built-in Trust Anchors
>>> 
>>>  The built-in bags and/or their trust anchors are immutable by
>>>  configuration operations.  Servers MUST ignore attempts to modify any
>>>  aspect of built-in bags and/or their trust anchors from <running>.
>>> 
>>> Is this really MUST ignore, or MUST reject?  I.e., Should they be rejecting any configuration attempt to modify the built-in bags and/or their trust anchors?  I think that this behaviour is consistent with the system datastore draft, but we should check.
>> 
>> Reject sounds more proper.  That said, this is one of the paragraphs I suggest removing, punting such mechanics to the system draft (and its continuations).
> [Rob Wilton (rwilton)]
> Yes, I agree to removing this.

Paragraph removed.  This item is resolved.





>>> But I guess that you also have the issue that if the trust anchors are completely copied into running and the trust store is subsequently updated out of band, then the certificates in the configuration differ from what is in trust-store (and hence system), and this is presumably an example of when they should be ignored.
>>> 
>>> My current expectation is that the system datastore will probably say that the running configuration always overrides the configuration in the system datastore, but this starts to look like a counter example, which potentially means that it may require special handling.
>> 
>> This is where the "immutable-flag" draft comes into play, so that it's clear when not allowed, and it shouldn't be allowed here.  If running wishes to use a different trust-anchor, then it should define a new trust-anchor and point to it, instead of hacking the built-in trust-anchor.
>> 
>> 
>> 
>>> Finally, are they still immutable even if copied into other parts of the configuration?  Presumably not, since at the point they are copied they lose their association with the built-in trust anchors.
>> 
>> No and true.  But then again, as soon as they're copied somewhere else in the config, they lose all history/association of having originated from a built-in, and therefore there's no need for the immutability to continue.
>> 
>> 
>> 
>> 
>>> (3) p 32, sec 6.2.  Informative References
>>> 
>>>  [I-D.ietf-netconf-trust-anchors]
>>>             Watsen, K., "A YANG Data Model for a Truststore", Work in
>>>             Progress, Internet-Draft, draft-ietf-netconf-trust-
>>>             anchors-19, 19 October 2022,
>>>             <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
>>>             trust-anchors-19<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-%0b             trust-anchors-19>>.
>>> 
>>> The same comment as for the other drafts about a document not referencing itself also applies here.
>> 
>> Please see my response to your similar comment in the crypto-types draft review regarding the Editor's Note.
> [Rob Wilton (rwilton)]
> Ack.  I think that the same solution is needed here, i.e., slightly clearer instructions to the RFC editor.

Done. This item is resolved.



>>> Minor level comments:
>>> 
>>> (4) p 3, sec 1.  Introduction
>>> 
>>>     Provide groupings that enable raw public keys and certificates to
>>>     be configured locally or as references truststore instances.
>>>     Enable the truststore to be instantiated in other data models, in
>>>     addition to or in lieu of the central truststore instance.
>>> 
>>> Would it be helpful to have a brief sentence in this document, and perhaps the keystore document that highlights the main differences between keystore and truststore.  Alternatively, you could reference another document that defines these.
>> 
>> 
>> Yes, it would be helpful, but folks can also read the abstracts of both docs, yes?
>> 
>> Also, all the first-page results from googling "truststore vs keystore" are accurate, AFAICT, suggesting that these are reasonably well-known concepts

Rob, your email ended here.  Did you have a comment to make on this item?  Beware that my response to you that you’re responding to contained even more items after this one.   Additionally, I noticed formatting issues in that the quote-levels weren’t being set (I reset them manually above).  Together, I wonder if your full-response was sent to the list…

Kent