Re: [netconf] built-in trust anchors

[Martin Björklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> 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).
> >> 
> >> 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; }
> >      }
> >    }
> >  }
> 
> 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.

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.

> 
> Related, please see my response just now to Tom.
> 
> 
> 
> 
> >> 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.
> > 
> > I much prefer Jürgen's proposal than haveing special rules for some
> > 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>?

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

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

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