Re: [OPSAWG] draft-ietf-opsawg-sbom-access and BRSKI ?

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 28 May 2021 22:08 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540503A37A7 for <opsawg@ietfa.amsl.com>; Fri, 28 May 2021 15:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 U99XvKsOq7kA for <opsawg@ietfa.amsl.com>; Fri, 28 May 2021 15:08:31 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855C53A37A3 for <opsawg@ietf.org>; Fri, 28 May 2021 15:08:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 18F4B38AE2; Fri, 28 May 2021 18:08:33 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ksNBk7h2H-un; Fri, 28 May 2021 18:08:32 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 06BFF38AE1; Fri, 28 May 2021 18:08:32 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DFBA31922; Fri, 28 May 2021 18:08:27 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Toerless Eckert <tte@cs.fau.de>, "opsawg@ietf.org" <opsawg@ietf.org>
In-Reply-To: <20210528151624.GL3909@faui48e.informatik.uni-erlangen.de>
References: <20210527233844.GE3909@faui48e.informatik.uni-erlangen.de> <11274.1622211801@localhost> <20210528151624.GL3909@faui48e.informatik.uni-erlangen.de>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 28 May 2021 18:08:27 -0400
Message-ID: <30292.1622239707@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/ZqXSpdcy42R0Z1dPg4uGpIs58DA>
Subject: Re: [OPSAWG] draft-ietf-opsawg-sbom-access and BRSKI ?
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2021 22:08:37 -0000

Toerless Eckert <tte@cs.fau.de> wrote:
    > On Fri, May 28, 2021 at 10:23:21AM -0400, Michael Richardson wrote:
    >>
    >> Toerless Eckert <tte@cs.fau.de> wrote: > SBOM is likely something many
    >> devices may want to keep confidential.
    >>
    >> I think that national security will eventually trump (might be a pun,
    >> not sure), emotional insecurities of manufacturers who made poor
    >> choices.

    > Can not quite parse this. Rephrase pls. I was just thinking about known
    > exploits for specific software versions as the reason for not making
    > the SBOM available to anyone who asks.

The need for all entities in all sorts of supply chains to know exactly what
possible issues there are.
This will lead to many audits, mandated by national security concerns.
Manufacturers who feel shy about revealing what they used, will find themselves
with multiple month delays at borders.
I also think that we are going towards mandatory disclosure of all breaches.

    > I ran into that problem i think
    > more than a decade ago when customers asked to not have software
    > version be included in LLDP information freely available to anyone on
    > the same LAN. Such as the virus infested employee PC whereas that virus
    > would hen easily find attackable network equipment. Not much different
    > when there is a well-known URL that such attacking systems could probe.

Right, "Think about the children".
So, now IT can't find the vulnerable PC either.
The malware never needed or cared about the LLDP version.
What's the proof?  The presence of virus infected PCs.

    >> We also already know how to integrate MUD with BRSKI, and this
    >> connects MUD with SBOM, so really, I don't think we need more.

    > So tell me, how do you think a registrar would be able to include SBOM
    > information in its decision whether to, or what certificate to give to
    > a pledge during the EST enrollment. I don't see a solution for that
    > without a solution like he one i proposed.  I may of course be missing
    > something.

Because SBOM is just an attribute that is part of remote attestation.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide