Re: [netconf] built-in trust anchors

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Jan 13, 2021 at 12:26:55PM +0100, Martin Björklund wrote:
> Juergen Schoenwaelder <[e-mail]> wrote:
> > 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.
> 
> This could work, but see below.
> 
> > 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 like the symmetry w/ hidden keys.  I assume that these entries would
> be explicitly marked in the config as being "built-in" or "hidden".
> 
> > 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.
> 
> 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.
>

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>