Subject: [netconf] built-in trust anchors

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 12 Jan 2021 19:02:04 +0000

Hi all,

I noticed Jurgen's comment about built-in trust anchors in his YANG doctor review of trust-anchors-13. I wanted to pull that out into a dedicated thread/discussion here.

Jurgen:

- Section 3 talks about populating <running> with built-in trust

  anchors.

   In order for the built-in trust anchors to be referenced by

   configuration, the referenced certificates MUST first be copied into

   <running>.  The certificates SHOULD be copied into <running> using

   the same "key" values, so that the server can bind them to the built-

   in entries.

  Is the idea that this copy operation is an explicit management

  operation or can implementations populate <running> with this

  data automatically?

I suppose a server *could* populate this in running as part of a built-in startup datastore in the absence of a startup datastore (i.e. as contents of a RFC8808 factory default). But I assume it is desirable to be able to delete the running copy of a built-in item. So the system would have to avoid populating these unless it is loading the factory default.

But even if the system can populate these, we'd also want the client/user to be able to explicitly populate them as well (i.e. in case they delete one from running, and want to add it back in to reference it).

In either case (system population of running, or client population of running), do we really need to put the contents of the bag or the cert into running?  Or is populating the list key enough since the operational copy shows what contents are in use for that list entry?

Jason

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Jan 2021 20:59:51 +0100

Jason,

since the leafref typedefs are weak references that do not require
that the certs/keys exist (there is no 'require-instance true'), it
may be OK to not have the certs/keys in <running> in terms of validity
of the <running> datastore.

Oops, I had to reread RFC 7950 (section 9.9.3): if require-instance is
not present, it defaults to true, so my review comment about weak
references is incorrect, these are actually strong references and
hence there is the need to copy what is referenced. Setting
require-instance to false may resolve this (but we loose the ability
to catch references to certs/keys that do not exist).

/js

> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 12 Jan 2021 22:59:28 +0000

Yes - adding require-instance false would eliminate the issue about built-in anchors in <running>. But there are useful advantages to keeping require-instance true. I don't have a strong feeling though one way or the other.

But assuming we keep require-instance true then the question still remains of how built-in items get into <running> (and are they deletable, and do we only need keys in running, etc).

Jason

> -----Original Message-----
> From: Juergen Schoenwaelder <[email-masked]>
> Sent: Tuesday, January 12, 2021 3:00 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
> Cc: Netconf <[email-masked]>
> Subject: Re: [netconf] built-in trust anchors
> 
> Jason,
> 
> > I noticed Jurgen's comment about built-in trust anchors in his YANG doctor
> review of trust-anchors-13. I wanted to pull that out into a dedicated
> thread/discussion here.
> >
> > Jurgen:
> >
> >
> > I suppose a server *could* populate this in running as part of a built-in
> startup datastore in the absence of a startup datastore (i.e. as contents of a
> RFC8808 factory default). But I assume it is desirable to be able to delete the
> running copy of a built-in item. So the system would have to avoid populating
> these unless it is loading the factory default.
> >
> > But even if the system can populate these, we'd also want the client/user
> to be able to explicitly populate them as well (i.e. in case they delete one
> from running, and want to add it back in to reference it).
> >
> > In either case (system population of running, or client population of
> running), do we really need to put the contents of the bag or the cert into
> running?  Or is populating the list key enough since the operational copy
> shows what contents are in use for that list entry?
> >
> > Jason
>

---

From: Qin Wu <[email-masked]>
Date: Wed, 13 Jan 2021 01:15:19 +0000

发件人: netconf [mailto:[email-masked]] 代表 Sterne, Jason (Nokia - CA/Ottawa)
发送时间: 2021年1月13日 3:02
收件人: Netconf <[email-masked]>
主题: [netconf] built-in trust anchors

Hi all,

Jurgen:

  anchors.

   in entries.

  data automatically?

[Qin]:Interesting discussion, either loading the factory default from factory datastore or define a new system datastore, I think both can enable the server to populate the data automatically, one of individual draft in NETCONF (draft-ma-netconf-with-system) seems to target to address this issue, i.e., avoid duplicated data items to be created in the running, I have copied this email to the author of draft-ma-netconf-with-system for their feedback.

[Qin]: See details in draft-ma-netconf-with-system. It helps define consistent behavior for system data handling, just like what RFC6243 did.

Jason

---

From: Martin Björklund <[email-masked]>
Date: Wed, 13 Jan 2021 09:23:25 +0100 (CET)

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]> wrote:
> Yes - adding require-instance false would eliminate the issue about
> built-in anchors in <running>. But there are useful advantages to
> keeping require-instance true. I don't have a strong feeling though
> one way or the other.

The current text has this:

   A server MUST reject attempts to modify any aspect of built-in trust
   anchors, both the certificates themselves and the bags that contain
   them.  That these certificates are "configured" in <running> is an
   illusion, as they are strictly a read-only subset of that which must
   already exist in <operational>.

This is really weird special handling of some config in <running>,
which goes against the idea that the client(s) "own" the contents of
<running>.

It is also not clear what happens if the set of built-in trust anchors
are changed during a software upgrade.  Will they be removed from
<running> automatically?  If so, <running> may become invalid with
dangling refrences.  If they are not removed, they will be stuck
there, since a client can't remove them.

I agree that strong references are preferred in most situations, but
in this case I think a weak reference is the best solution.  It has
it's own set of problems that must be solved though, specifically what
happens if the target doesn't exist.

> But assuming we keep require-instance true then the question still
> remains of how built-in items get into <running> (and are they
> deletable, and do we only need keys in running, etc).

I think these lists have some mandatory elements, which means that you
can't just copy the keys.

/martin

> > On Tue, Jan 12, 2021 at 07:02:04PM +0000, Sterne, Jason (Nokia -
> > CA/Ottawa)
> > wrote:
> > > Hi all,
> > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Jan 2021 09:29:18 +0100

After sleeping over it, I think a device should ship with the keys
listed in whatever is the equivalent of the factory default, i.e.,
they are initially in <running>. Deleting them should be possible with
the effect that no config can refer to these keys anymore (assuming
strong references). Putting the keys back into running makes them
available for config again.

I would be in favour to just have the names in runnning, not the
key/cert details. This avoids issues with entries that do not match,
and this then resembles hidden keys, for which details are also not
known in <running>. In fact, <hidden> keys likely have the same
property that they exist in the system (or a TPM), i.e., they are not
config that can be arbitrary changed. I would assume that the same
rules apply, if you delete a hidden key from <running>, it can't be
referenced and used anymore. Perhaps the discussion in the I-D should
be expanded to cover hidden keys as well.

I also expect that these special keys may be part of the firmware,
i.e., they may change with firmware updates. This can lead to stale
special keys that do not exist anymore in the firmware and new keys
that exist in the firmware but must be (manually) added to <running>
in order to use them.

/js

---

From: Martin Björklund <[email-masked]>
Date: Wed, 13 Jan 2021 12:26:55 +0100 (CET)

> available for config again.

This could work, but see below.

> be expanded to cover hidden keys as well.

I like the symmetry w/ hidden keys.  I assume that these entries would
be explicitly marked in the config as being "built-in" or "hidden".

> that exist in the firmware but must be (manually) added to <running>

So then the question is what happens if a key is removed from the
firmware, but it exists (with just the name) in the config, and some
part of the config reference it?

I think that this leads to the same problem as a weak leafref would
do, so either solution would work.

/martin

---

From: "maqiufang (A)" <[email-masked]>
Date: Wed, 13 Jan 2021 13:14:50 +0000

Hi , Qin,

Thanks for bringing up this topic.
You are right, the mechanism defined in our draft aims at solving this issue.
We proposed a "system" datastore,  and  there are two system configuration data handling basic modes. One is automatically  loading system into running,
The other is the client explicitly populates running with system configuration.
It allows the client to identify how system configuration are processed by the server, and also define a new mechanism for client control of server processing of system configuration data.

Any suggestions and comments would be greatly appreciated.

Qiufang Ma

发件人: Qin Wu
发送时间: 2021年1月13日 9:15
收件人: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; Netconf <[email-masked]>
抄送: [email-masked]
主题: RE: built-in trust anchors

发件人: netconf [mailto:[email-masked]] 代表 Sterne, Jason (Nokia - CA/Ottawa)
发送时间: 2021年1月13日 3:02
收件人: Netconf <[email-masked]<mailto:[email-masked]>>
主题: [netconf] built-in trust anchors

Hi all,

Jurgen:

  anchors.

   in entries.

  data automatically?

Jason

---

From: "maqiufang (A)" <[email-masked]>
Date: Wed, 13 Jan 2021 13:22:31 +0000

Hi, Juergen,

Apologize for my chiming in, I agree that setting require-instance as false can mitigate this issue, but cannot completely solve it.

Think differently,  we could introduce a system configuration datastore which might be implement using TPM. And it can update running with the system configuration automatically, after the system configuration has been altered as a consequence of device rebooting, inserting/removing a NIC , firmware updates as you mentioned, and so on.
In this case, the client do not have to copy the referenced certificates into <running> explicitly.
It should also be deletable, but it will be reloaded into running again if the system configuration is still present in the system.

In fact, this is exactly one of the motivation we proposed the draft (https://tools.ietf.org/html/draft-ma-netconf-with-system-01), i.e., how built-in items get into <running>. another motivation is to provide a mechanism for system configuration retrieval since not all server implementations treat the system configuration data in the same way.

Qiufang Ma

-----邮件原件-----
发件人: netconf [mailto:[email-masked]] 代表 Juergen Schoenwaelder
发送时间: 2021年1月13日 16:29
收件人: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
抄送: Netconf <[email-masked]>
主题: Re: [netconf] built-in trust anchors

After sleeping over it, I think a device should ship with the keys listed in whatever is the equivalent of the factory default, i.e., they are initially in <running>. Deleting them should be possible with the effect that no config can refer to these keys anymore (assuming strong references). Putting the keys back into running makes them available for config again.

I would be in favour to just have the names in runnning, not the key/cert details. This avoids issues with entries that do not match, and this then resembles hidden keys, for which details are also not known in <running>. In fact, <hidden> keys likely have the same property that they exist in the system (or a TPM), i.e., they are not config that can be arbitrary changed. I would assume that the same rules apply, if you delete a hidden key from <running>, it can't be referenced and used anymore. Perhaps the discussion in the I-D should be expanded to cover hidden keys as well.

I also expect that these special keys may be part of the firmware, i.e., they may change with firmware updates. This can lead to stale special keys that do not exist anymore in the firmware and new keys that exist in the firmware but must be (manually) added to <running> in order to use them.

/js

On Tue, Jan 12, 2021 at 10:59:28PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote:
> > may be OK to not have the certs/keys in <running> in terms of 
> > validity of the <running> datastore.
> > 
> > Oops, I had to reread RFC 7950 (section 9.9.3): if require-instance 
> > is not present, it defaults to true, so my review comment about weak 
> > review of trust-anchors-13. I wanted to pull that out into a 
> > dedicated thread/discussion here.
> > >
> > > Jurgen:
> > >
> > >
> > RFC8808 factory default). But I assume it is desirable to be able to 
> > delete the running copy of a built-in item. So the system would have 
> > to avoid populating these unless it is loading the factory default.
> > >
> > to be able to explicitly populate them as well (i.e. in case they 
> > delete one from running, and want to add it back in to reference it).
> > >
> > running), do we really need to put the contents of the bag or the 
> > cert into running?  Or is populating the list key enough since the 
> > operational copy shows what contents are in use for that list entry?
> > >
> > > Jason
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Jan 2021 16:09:34 +0100

> do, so either solution would work.

You will have a reference to a key that is not usable, which means you
get runtime failures (as you would get with certs that have expired or
other issues). Note that this is only becoming a problem if the
firmware update renames keys/certs. If the update only ships a new
keys/certs but keeps the names consistent, things will continue to
work. I can't tell whether this brittleness is something to be
concerned about or whether it falls into the usual 'things may go
wrong after an update' bag of surprises.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 13 Jan 2021 16:30:37 +0000

[Top-posting as this is a response to the entire thread, sans draft-ma-netconf-with-system, which I haven’t looked at yet].

Having "instance-required false” was an idea from before, but it didn’t make sense to disable validation for the 99% use-case to enable a 1% use-case.  There will only ever be a few built-in keys/certs (typically at most just one of each, to enable bootstrapping), whereas potentially many keys/certs will be configured over time (for normal ops).

Hiding all the descendent nodes except “name” for built-in keys/certs doesn’t work because the pubkey/cert is needed in order to encrypt data that only a device can decrypt, as needed to support RMA scenarios (see https://tools.ietf.org/html/draft-ietf-netconf-keystore-20#section-4.3 <https://tools.ietf.org/html/draft-ietf-netconf-keystore-20#section-4.3> starting with the 4th paragraph).

The built-in keys/certs are envisioned to be forever; they never expire nor are affected by firmware updates.  For the example of a list of public CAs (trust anchors such as Verisign, RSA, etc.), these SHOULD be in <startup> and admins SHOULD be allowed (NACM permitting) to add/remove entries.

I agree that the “illusion” text Martin quoted is "weird special handling”, but this was the best that could be envisioned after several tries.  You might recall there were two or three other variations (inc. the "instance-required false” mentioned above) that we tried before landing on this approach.

K.

> On Jan 13, 2021, at 10:09 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Martin Björklund <[email-masked]>
Date: Thu, 14 Jan 2021 08:46:21 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> [Top-posting as this is a response to the entire thread, sans
> draft-ma-netconf-with-system, which I haven’t looked at yet].
> 
> Having "instance-required false” was an idea from before, but it
> didn’t make sense to disable validation for the 99% use-case to enable
> a 1% use-case.  There will only ever be a few built-in keys/certs
> (typically at most just one of each, to enable bootstrapping), whereas
> potentially many keys/certs will be configured over time (for normal
> ops).

Ok.

> Hiding all the descendent nodes except “name” for built-in keys/certs
> doesn’t work because the pubkey/cert is needed in order to encrypt
> data that only a device can decrypt

I don't understand this.  The descendent nodes would not be present in
'running', but they would be present in <operational> (b/c they are
present in the firmware).

>, as needed to support RMA
> scenarios (see
> https://tools.ietf.org/html/draft-ietf-netconf-keystore-20#section-4.3
> <https://tools.ietf.org/html/draft-ietf-netconf-keystore-20#section-4.3>
> starting with the 4th paragraph).
> 
> The built-in keys/certs are envisioned to be forever; they never
> expire nor are affected by firmware updates.

:)

> For the example of a
> list of public CAs (trust anchors such as Verisign, RSA, etc.), these
> SHOULD be in <startup> and admins SHOULD be allowed (NACM permitting)
> to add/remove entries.
> 
> I agree that the “illusion” text Martin quoted is "weird special
> handling”, but this was the best that could be envisioned after
> several tries.  You might recall there were two or three other
> variations (inc. the "instance-required false” mentioned above) that
> we tried before landing on this approach.

Since this problem comes up every now and then, it would be good with
a design pattern that can work in other cases as well.  It seems that
the "hidden" design already used in crypto-types can be used in this
case, as Jürgen suggested.  I don't remember this propsal from the
previous discussion; was it discussed?

/martin

> 
> K.
> 
> 
> > On Jan 13, 2021, at 10:09 AM, Juergen Schoenwaelder
> > <[email-masked]> wrote:
> >

---

From: tom petch <[email-masked]>
Date: Thu, 14 Jan 2021 11:49:42 +0000

From: netconf <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Sent: 13 January 2021 16:30
[Top-posting as this is a response to the entire thread, sans draft-ma-netconf-with-system, which I haven’t looked at yet].

<tp>
depends where you are.  For me, the great advance in Internet security was when Microsoft built in the certificates I needed to access sites securely, in the shrink-wrapped software.  I do not know how many there are but it is now rare for me to need to add one.

By contrast other certificates are ephemeral, used for a session and then discarded.

I can guess the model you have in mind but suspect that it is not the common one when looking at security across the Internet as a whole.

Tom Petch

Hiding all the descendent nodes except “name” for built-in keys/certs doesn’t work because the pubkey/cert is needed in order to encrypt data that only a device can decrypt, as needed to support RMA scenarios (see https://tools.ietf.org/html/draft-ietf-netconf-keystore-20#section-4.3 starting with the 4th paragraph).

K.

On Jan 13, 2021, at 10:09 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

/js

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Jan 2021 16:27:24 +0000

Hi Martin,

> On Jan 14, 2021, at 2:46 AM, Martin Björklund <[email-masked]> wrote:
> 

Update: I did look at this draft and found the motivation unclear.

> present in the firmware).

I think that there is a misunderstanding somewhere.  It might be helpful for me to clarify that, at a high-level: 1) the drafts only present a *configuration* model, and that 2)  it’s possible that some “config” only shows up in <operational>, when the values are “built-in”.

For the “config” that only shows in <operational>, it’s necessary to promote them to <running> in order for leafrefs to resolve.  I agree that only the “name” is needed, but we lack a mechanism to just configure a name as otherwise 1) validation would fail because "mandatory true” descendants would fail validation and 2) there’s no way to tell “apply config” process to not-delete the missing values.

> a design pattern that can work in other cases as well.  

I agree the patterns are good, but disagree that *this* come up once in awhile or, for that matter, ever before…and likely never again (at least not within my understanding).

> It seems that
> case, as Jürgen suggested.

Please note that the value is hidden in <operational> originally.   This is because, e.g., it is impossible to extract a private key value from a TPM.   Regardless, the net-net is that the value is “hidden” in both <operational> *and* <running> (when the asymmetric key has been copied into <running>).   To be clear, hidden private keys nodes still appear in <running> (they are *not* missing) and have the same value as appears in <operational>.

>  I don't remember this propsal from the

We’ve been discussing these drafts for a long time, and you know that I’ve been careful to communicate pretty much everything along the way…

Looking at the keystore draft's Change Log, I see that the “require-instance false” idea was added in -05 (June 2018) and removed in -07 (April 2019).  

As for “hidden”, the current approach arrived in crypto-types-08.  Previously, the node was a ‘union’ with "permanently-hidden” being an enumerated value.  This idea was moved into crypto-types-01 from 
keystore-06.  It was called "hardware-protected” in keystore 03-05, and “INACCESSIBLE” in keystore 01-02.

We also explored letting the private-key value be "mandatory false” somewhere along the line.  Without digging for dates, I’m sure the reason we backed out of it is because, again, it didn’t make sense to do it for a 1% use case.

K.

---

From: Martin Björklund <[email-masked]>
Date: Thu, 14 Jan 2021 18:25:50 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> I think that there is a misunderstanding somewhere.  It might be
> helpful for me to clarify that, at a high-level: 1) the drafts only
> present a *configuration* model, and that 2) it’s possible that some
> “config” only shows up in <operational>, when the values are
> “built-in”.
> 
> For the “config” that only shows in <operational>, it’s necessary to
> promote them to <running> in order for leafrefs to resolve.  I agree
> that only the “name” is needed, but we lack a mechanism to just
> configure a name as otherwise 1) validation would fail because
> "mandatory true” descendants would fail validation and 2) there’s no
> way to tell “apply config” process to not-delete the missing values.

It can be done by doing something similar to "hidden", here's a sketch
of the idea:

  list certificate-bag {
    key name;
    leaf name { ... }
    choice type {
      case inline {
        list certificate { ... }
      }
      case built-in {
        leaf built-in { type empty; }
      }
    }
  }

> I agree the patterns are good, but disagree that *this* come up once
> in awhile or, for that matter, ever before…and likely never again (at
> least not within my understanding).
> 
> 
> > It seems that
> Please note that the value is hidden in <operational> originally.
> This is because, e.g., it is impossible to extract a private key value
> from a TPM.  Regardless, the net-net is that the value is “hidden” in
> both <operational> *and* <running> (when the asymmetric key has been
> copied into <running>).  To be clear, hidden private keys nodes still
> appear in <running> (they are *not* missing) and have the same value
> as appears in <operational>.

Yes.

> We’ve been discussing these drafts for a long time, and you know that
> I’ve been careful to communicate pretty much everything along the way…

Absolutely, this is much appreciated!

> Looking at the keystore draft's Change Log, I see that the
> “require-instance false” idea was added in -05 (June 2018) and removed
> in -07 (April 2019).
> 
> As for “hidden”, the current approach arrived in crypto-types-08.
> Previously, the node was a ‘union’ with "permanently-hidden” being an
> enumerated value.  This idea was moved into crypto-types-01 from
> We also explored letting the private-key value be "mandatory false”
> somewhere along the line.  Without digging for dates, I’m sure the
> reason we backed out of it is because, again, it didn’t make sense to
> do it for a 1% use case.

I much prefer Jürgen's proposal than haveing special rules for some
nodes in <running>.  Especially if it falls into this "1%" bucket.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Jan 2021 18:27:58 +0000

Hi Tom,

> I can guess the model you have in mind but suspect that it is not the common one when looking at security across the Internet as a whole.

Please see https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-13#section-3 <https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-13#section-3>.

I think the question we need to ask ourselves is:

    Are “Built-In” Public CA Certs:
      1) read-only
      2) hybrid       (sys-defined entries are read-only, new values MAY be added)
      3) read/write (sys-defined entries are read-write, new values MAY be added)

The link above reflects #1.

In this case, just the “bag” itself is forever, whereas the certs within are free to come and go as the OS-provider desires.  This is fine as, in configuration, a TLS-client only refs the bag (see 3.1.2.1 in the tls-client-server draft, and note that it refs 2.1.3.1 in the truststore draft, which uses a "ts:certificate-bag-ref”).

As currently defined, #3 is supported by an administrator copying the “built-in” bag to custom bag “e.g., “My Public CA Certs”) and hack on them from there.  (note: I misspoke in my previous msg when I said the certs could be in <startup>, which is still possible, albeit less desirable IMO)

If that seems too coarse and #2 seems like a sweet-spot, then I think we could just change the text in https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-13#section-3 <https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-13#section-3> to allow it.  Specifically, the sentence:

      "No certificates may be added or changed; that is, the certificates in
       <running> MUST be a subset (which includes the whole of the set)
       of the built-in certificates define in <operational>.”

…could be tweaked to allow additions of new certificates while still 1) disallowing modification of any existing certificate and 2) only requiring the (subset of) certificates that are directly-referenced to be copied in <running> (note that it MAY be that no certs are copied, i.e., an empty bag).

PS: I have for a long time had difficulty reading your responses.  Can you investigate configuring your SMTP-client to support threading (i.g., indenting blocks) and/or trim messages down so that only relevant parts are visible?

K.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Jan 2021 20:30:55 +0000

Hi Martin,

>        leaf built-in { type empty; }

Thank you for the example.  It's infinitely easier to understand what folks intend when examples are provided.

Yes, your model enables just the “name” node to appear, but I’m confused/concerned by its implications...

In particular, what would be in <operational> in a device as shipped from Manufacturing?  It can’t be “built-in” because the certificate data must be accessible.  But, assuming it’s “inline”, then we’d expect “inline” in <running> too, right?  If not, then we're devising yet other special case rules that are no better than those described in the truststore draft.  Worse, how to reference specific certs (not the bag), as is needed in some cases (not a TLS-client), becomes even more complicated.

Related, please see my response just now to Tom.

> nodes in <running>.  Especially if it falls into this "1%" bucket.

Do you mean that built-in values should be in <factory-default>, not <operational>?

It is an interesting idea, and one I hadn’t considered before, but:

1) there would still be a need for special-case rules ensuring that descendent nodes of “built-in” (read-only) keys/certs are never changed. E.g., consider a built-in (TPM-protected) key having an associated IDevID cert, nothing about it can vary.

2) how do vendor-updates for the built-in public CA certs get picked up?  Do we suggest that operators re-merge that part of <factory-default> into their <running> after each OS update?  (And what if the update occurs via ZTP and somehow that new cert is needed then?)

3) looking to my response to Tom, the proposal supports #3 - is this what we want?   I personally think that deleting built-in public CA certs is a questionably bad idea (too many things can break).  #2 is “okay” (at least nothing breaks), but some may question if it’s ever needed (i.e., rather than merge a new cert into the existing bag, it may be better to put it in its own bag and have the TLS-client point that bag instead).  #1 is the most conservative, perhaps to a fault, but in the world of security, sometimes that is what’s needed.

4) it seems that it may be possible to use alternate cert-data for a “built-in” cert.  E.g., consider a built-in public CA cert called “Verisign Root CA 2009-2”, it would be possible to configure a cert having that name/key but with a different base64 value, potentially opening up an attack vector.  My intention for #3 was “all or nothing”, that is, certs can be present or deleted in their entirety, nothing in-between. 

5) The entire contents of the built-in public CA certs bag would have to be copied into <running>, cluttering it up unnecessarily with a bunch of base64 strings representing the contents of, e.g., /etc/ssl/certs/.  Maybe this is okay, but it would likely be unwelcomed by many.

My seems that the currently documented approach (tweaked per my email to Tom) is still the simplest, agreed?   Yes, there are special case rules, but they’re simple (“treat built-in values as read-only”).

K.

---

From: Martin Björklund <[email-masked]>
Date: Mon, 18 Jan 2021 08:43:34 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> Yes, your model enables just the “name” node to appear, but I’m
> confused/concerned by its implications...
> 
> In particular, what would be in <operational> in a device as shipped
> from Manufacturing?  It can’t be “built-in” because the certificate
> data must be accessible.  But, assuming it’s “inline”, then we’d
> expect “inline” in <running> too, right?  If not, then we're devising
> yet other special case rules that are no better than those described
> in the truststore draft.

No I don't agree that all nodes in <running> must exactly match what's
in <operational>.  This is not a special case.  <operational> is
designed to reflect reality, so things may not match what's in
<running>.

> Worse, how to reference specific certs (not
> the bag), as is needed in some cases (not a TLS-client), becomes even
> more complicated.

So then we need to adjust the data model to allow this.  Perhaps not
use a choice like I did above, but simply a leaf that indicates that
the bag is builtin, and then allow certs to be set in <running> as
well.

> Do you mean that built-in values should be in <factory-default>, not

Yes, but if they are added via <factory-defaults> or not is imo
important.  If the device doesn't have <factory-defaults>, a client
can simply add them to <running>.

> 1) there would still be a need for special-case rules ensuring that
> descendent nodes of “built-in” (read-only) keys/certs are never
> changed. E.g., consider a built-in (TPM-protected) key having an
> associated IDevID cert, nothing about it can vary.

I don't think special rules are needed.

> 2) how do vendor-updates for the built-in public CA certs get picked
> up?  Do we suggest that operators re-merge that part of
> <factory-default> into their <running> after each OS update?  (And
> what if the update occurs via ZTP and somehow that new cert is needed
> then?)

I think this problem is present with your proposed solution as well.

> 3) looking to my response to Tom, the proposal supports #3 - is this
> what we want?  I personally think that deleting built-in public CA
> certs is a questionably bad idea (too many things can break).  #2 is
> “okay” (at least nothing breaks), but some may question if it’s ever
> needed (i.e., rather than merge a new cert into the existing bag, it
> may be better to put it in its own bag and have the TLS-client point
> that bag instead).  #1 is the most conservative, perhaps to a fault,
> but in the world of security, sometimes that is what’s needed.

If the system can handle the case that a cert that is marked as
built-in in running doesn't exist (see thread w/ Jürgen), then #3 is
ok.

> 4) it seems that it may be possible to use alternate cert-data for a
> “built-in” cert.  E.g., consider a built-in public CA cert called
> “Verisign Root CA 2009-2”, it would be possible to configure a cert
> having that name/key but with a different base64 value, potentially
> opening up an attack vector.  My intention for #3 was “all or
> nothing”, that is, certs can be present or deleted in their entirety,
> nothing in-between.

I'm not sure I follow you, but nothing prevents the system to ignore
unwanted data in <running> for built-in certs, and use the
system-provided values instead.

> 5) The entire contents of the built-in public CA certs bag would have
> to be copied into <running>, cluttering it up unnecessarily with a
> bunch of base64 strings representing the contents of, e.g.,
> /etc/ssl/certs/.  Maybe this is okay, but it would likely be
> unwelcomed by many.

I don't understand why this is needed.

> My seems that the currently documented approach (tweaked per my email
> to Tom) is still the simplest, agreed?  Yes, there are special case
> rules, but they’re simple (“treat built-in values as read-only”).

They may look innocent, but this is a slippery slope.  The proposal in
the draft goes against the NMDA architure, see section 5 of RFC 8342.
"system configuration" goes into <operational>, NOT into <running>.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 20 Jan 2021 02:18:31 +0000

Hi Martin,

Yes.

> the bag is builtin, and then allow certs to be set in <running> as

First we should decide if operators should be allowed to add certificates to built-in bags (i.e. #2 in my message to Tom).

> can simply add them to <running>.

I’m unable to parse fully what you mean.  In any case, built-in stuff being in <factory-default> is a convenience, to have it in <running> at first boot, assuming that is necessary (I don’t think it is).  The draft says built-in certs/keys are in <operational>, just like built-in interfaces (e.g., loopback) in RFC 8342.

> I don't think special rules are needed.

True, servers can already ignore/override <intended> to reflect reality.  

> I think this problem is present with your proposed solution as well.

Yes and No.  

The only problem is that the intention of the words in the “Support for Built-in Trust Anchors” section isn’t completely realized by the model.  This section talks about what needs to be done in order to reference “certificates”, which is still true, sans it should be that servers must ignore (not “reject") attempts to modify built-ins.  

What’s missing is what needs to be done to reference a built-in *bag* that has not had any operator-specified certs added to it (i.e., an “empty” bag, in <running> only).  Your "case built-in” above addresses that case, as well could an empty list, which is even simpler.

> built-in in running doesn't exist (see thread w/ Jürgen), then #3 is

Regarding “then #3 is ok”, regardless if #3 is possible, I don’t think we want to support it.   #1 is safe, #2 is okay, #3 is potentially dangerous and the use case is weak.

> system-provided values instead.

Yes (same realization as above)

> I don't understand why this is needed.

Maybe I misunderstood what you or Jürgen were trying to say before.  So long as we agree that it would be a usability-fail, then I’m fine.

>> It seems that the currently documented approach (tweaked per my email

The draft is completely in line with NMDA, sans the s/reject/ignore/ bit mentioned above.  Where do you see otherwise?

K.

---

From: "maqiufang (A)" <[email-masked]>
Date: Wed, 20 Jan 2021 13:26:22 +0000

Hi, Kent:

-----Original Message-----
From: netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Wednesday, January 20, 2021 10:19 AM
To: Martin Björklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] built-in trust anchors

Hi Martin,

>>>>>> Hiding all the descendent nodes except “name” for built-in 
>>>>>> keys/certs doesn’t work because the pubkey/cert is needed in 
>>>>>> order to encrypt data that only a device can decrypt
>>>>> 
>>>>> I don't understand this.  The descendent nodes would not be 
>>>>> present in 'running', but they would be present in <operational> 
>>>>> (b/c they are present in the firmware).
>>>> 
>>>> present a *configuration* model, and that 2) it’s possible that 
>>>> some “config” only shows up in <operational>, when the values are 
>>>> “built-in”.
>>>> 
>>>> For the “config” that only shows in <operational>, it’s necessary 
>>>> to promote them to <running> in order for leafrefs to resolve.  I 
>>>> agree that only the “name” is needed, but we lack a mechanism to 
>>>> just configure a name as otherwise 1) validation would fail because 
>>>> "mandatory true” descendants would fail validation and 2) there’s 
>>>> no way to tell “apply config” process to not-delete the missing values.
>>> 
>>> It can be done by doing something similar to "hidden", here's a 
>>> sketch of the idea:
>>> 
>>> list certificate-bag {
>>>   key name;
>>>   leaf name { ... }
>>>   choice type {
>>>     case inline {
>>>       list certificate { ... }
>>>     }
>>>     case built-in {

Yes.

>> Worse, how to reference specific certs (not the bag), as is needed in 
>> some cases (not a TLS-client), becomes even more complicated.
> 

>>>> “require-instance false” idea was added in -05 (June 2018) and 
>>>> removed in -07 (April 2019).
>>>> 
>>>> Previously, the node was a ‘union’ with "permanently-hidden” being 
>>>> an enumerated value.  This idea was moved into crypto-types-01 from 
>>>> reason we backed out of it is because, again, it didn’t make sense 
>>>> to do it for a 1% use case.
>>> 

[Qiufang Ma]: I got a little confused.
This seems contradicted against what Juergen has clarified at https://mailarchive.ietf.org/arch/msg/netmod/3FtVJ3lfrNIms3OAgmftrvGxvzo/ .
As <factory-default> could be empty, I think build-in items should be in <operational> , rather than <factory-default>.

Yes and No.  

K.