Re: [netconf] built-in trust anchors

Martin Björklund <mbj+ietf@4668.se> Mon, 18 January 2021 07:43 UTC

Return-Path: <mbj+ietf@4668.se>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8194C3A1110 for <netconf@ietfa.amsl.com>; Sun, 17 Jan 2021 23:43:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.123
X-Spam-Level:
X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=BQMeEjGz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CMoqH6iX
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cibhr3kt-NSR for <netconf@ietfa.amsl.com>; Sun, 17 Jan 2021 23:43:39 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23873A09EA for <netconf@ietf.org>; Sun, 17 Jan 2021 23:43:39 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id A601A14A6; Mon, 18 Jan 2021 02:43:38 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 18 Jan 2021 02:43:38 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= ouOsbAoaUxRVoDsFL35uKHqM+AcJ5UK1img2ao2R1HY=; b=BQMeEjGzekWvDoPB aD5DgwCywJ+xUnVhCXZgZARH7zgtOn7CCpJYNfBZpuqHVlUa4yVQ+uoRTm4YDCdN hFfPMhsH0LTm+uNdzZ8BNL2KU7k+EC+EyPEi/mHV5XM+dq3+hLxEvGhpB2fov2JO R4v21rpUkTfhXMVx67UIp97I9/iYzrVYHxi2MJQIs4PnEgU6xpxWa19mswOHx+y5 oGRq8agUZXXbPmyHaWslR4+6FCksOYdDIAcVIf+UKpVNAAeaz00xJ2JoxltC61DG 6PYjsM/Drkwzb8c3zU9xz9d9vDWMmwQw8sQfU9gsbSe7pM+Lgwq/viKagfUexH5a SNnQog==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ouOsbAoaUxRVoDsFL35uKHqM+AcJ5UK1img2ao2R1 HY=; b=CMoqH6iXlQaYcMTWboaTcP0Pd+sHLM6XaR5C2QV2KILtngz+mtuVxleHJ g5iWP0Vdgs4BYT9vdaIc+56ZPUfEW1aRWiaD91DEDB+xXqDV8WU+XKfTj9G6fNJt QACLMx1EJqRlFg/fTfHvHHxyqS6aLNn3DUvG0ha9hf7Oni9IO4qrqqyAutalNhxE z8C0ix8/1nyRTzBIG/0QqtTnpS5tuMzpdr+NmnZybKOY4EmK+5B+KmXui+ZYabZv D7q5FpiHQpYBQvkTh2iOemFEGrHaZ7DY5x3jS+NDEwOdv/Jrd1tbZAJyzgRb89xm DkMqIr6l2sOLEk4VCgGJww7Um9NRQ==
X-ME-Sender: <xms:KTwFYFiGMTEpuZ4SnvFiSd-icPL9QVppJ4teYXYy4okmKHrDJjDjmw> <xme:KTwFYKBf3-FBze8IyP68Tq2N8VXk3LKVghcjKdOfnLQrZBKrWXRoMY1IYEc6uYbnL DYqyx1gd6A6H5z5V-E>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtdejgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepheetgedtfffggeffkedvje ekveelteeuuddttdffhfelgfetvdevhedvgeeutddunecukfhppeduheekrddujeegrdeg rddvudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhgsjhdoihgvthhfseegieeikedrshgv
X-ME-Proxy: <xmx:KTwFYFHP5brv3R9Lz2TlrDVlVEuxcQMSurtCDsppIofgHH3VhtkySA> <xmx:KTwFYKR3q638AFCiZzjcKhBCqOiP2xzeeIKCgCI5TKDy8k1cxAzXzw> <xmx:KTwFYCwN8760nAH96pTZrfohnXY329xjimM0OiJ_drYK6r8qHa0rvA> <xmx:KjwFYHvmE3yhVvA9U6_ObGHovY-bach-5BWl8w68qRzxJiIyUAu2WQ>
Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 23511108005B; Mon, 18 Jan 2021 02:43:37 -0500 (EST)
Date: Mon, 18 Jan 2021 08:43:34 +0100 (CET)
Message-Id: <20210118.084334.2073692074145182067.id@4668.se>
To: kent+ietf@watsen.net
Cc: netconf@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <0100017702980f9a-46c72646-4158-42bf-a15f-842281b70d72-000000@email.amazonses.com>
References: <0100017701b91b90-5b4fac25-1818-41c2-be81-4f57296fe9d2-000000@email.amazonses.com> <20210114.182550.2075205444128224956.id@4668.se> <0100017702980f9a-46c72646-4158-42bf-a15f-842281b70d72-000000@email.amazonses.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/XuN9ogxPDVIOj_INatUm2LBTTQ8>
Subject: Re: [netconf] built-in trust anchors
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jan 2021 07:43:42 -0000

Kent Watsen <kent+ietf@watsen.net> 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