Re: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

Dick Brooks <dick@reliableenergyanalytics.com> Fri, 11 June 2021 10:59 UTC

Return-Path: <dick@reliableenergyanalytics.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C4D3A3374 for <suit@ietfa.amsl.com>; Fri, 11 Jun 2021 03:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 3v_Y9yqteBTp for <suit@ietfa.amsl.com>; Fri, 11 Jun 2021 03:59:01 -0700 (PDT)
Received: from forward4-smtp.messagingengine.com (forward4-smtp.messagingengine.com [66.111.4.238]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 571D13A3372 for <suit@ietf.org>; Fri, 11 Jun 2021 03:59:01 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailforward.nyi.internal (Postfix) with ESMTP id 4D6081940A9C; Fri, 11 Jun 2021 06:58:59 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 11 Jun 2021 06:58:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:reply-to:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=s79Uwz1ta8CtKeDrsiJEgL44SrhXTTUxariW0BPDcVA=; b=aawHX2Le w3IcQXFnrmwVHQnAs60vO1DWK6kIgYXkGK7J7EA+NECR0XkB1e+iOzEgU09aIzTc a3MsO6HDvXANe3uk6s3W6KMqogLi+PSVrZQssOwrRtyw6SzJBTVSj7Z4RzWIuVKr Of+EmCQCvVUfYAYmk45p26fQMmwEg3aZHaAxzsSLiNUsz3t7uQ5sxpMexSqSG2vc an3xjAI3+DdJRWiKAV+7RPSqfW/+03PZpMHn2IoC+yJUwxnV7DUeu37QBKEaCZjJ Gzg2jsEOHDXCChnds+QGl9Ksi0st+Hh2Jwtl/qn4jMcruN0KB9DUo+Gr4HEzmPRZ CP6GT6PkUEilBw==
X-ME-Sender: <xms:8kHDYK-w9XT424IFzrPIpbvqS432twi6Ra0UetNLLuvFvzJ1wlSJaQ> <xme:8kHDYKuQo3SK2xO6QRswofQq3IWSSo5tjo8T4OI7YnFLDufKt3XOTTH3PlOP_U5Gk O-gMqgcpsXQw9QDyQ>
X-ME-Received: <xmr:8kHDYACTojzqaKbxkdwNl2B0FfWo9Ul4WFu0oFCZWENqdkKN7h3VFh8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedujedgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheprhfhvfhfjgfuffhokfggtgfothesrhdtghepvddtjeenucfhrhhomhepfdff ihgtkhcuuehrohhokhhsfdcuoeguihgtkhesrhgvlhhirggslhgvvghnvghrghihrghnrg hlhihtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepueduvdfhtdetueeugfehgfff geeigeekfedvfedtteefudelgeeijedtudevvdevnecuffhomhgrihhnpehrvghlihgrsg hlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhmnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepughitghksehrvghlihgrsghlvggvnhgvrh hghigrnhgrlhihthhitghsrdgtohhm
X-ME-Proxy: <xmx:8kHDYCcDLqq-q6OJ6rZDrRRILquYIp5C9FEXW3rf1Fyz_2h36ziZBw> <xmx:8kHDYPMlpMIwBhi8fBLb3T0Ew6EN7NpsKvfM_eJP6doEh1JgtsaA7g> <xmx:8kHDYMkW55DtUr6Zg8IlWgku-zgQk_zaW7pamPZwpL68WawSjMUZ-Q> <xmx:80HDYIbepDCnDA3TJm2FgQh_XfrF1Rfb0MlHY94XTfluIzcOKH1kug>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 11 Jun 2021 06:58:58 -0400 (EDT)
Reply-To: dick@reliableenergyanalytics.com
From: Dick Brooks <dick@reliableenergyanalytics.com>
To: 'Hannes Tschofenig' <Hannes.Tschofenig@arm.com>, 'Phillip Hallam-Baker' <phill@hallambaker.com>
Cc: 'Brendan Moran' <Brendan.Moran@arm.com>, 'suit' <suit@ietf.org>, 'Russ Housley' <housley@vigilsec.com>
References: <0f9601d75adf$5856cf50$09046df0$@reliableenergyanalytics.com> <DBBPR08MB59155DB5DBE123F55B25894BFA359@DBBPR08MB5915.eurprd08.prod.outlook.com> <CAMm+Lwg36Y-tpB+XTwYYpC3psCNEj3O33BzrnzzC8gtMjgkD3Q@mail.gmail.com> <DBBPR08MB5915A4EAB8B59778AD9DCAD9FA349@DBBPR08MB5915.eurprd08.prod.outlook.com>
In-Reply-To: <DBBPR08MB5915A4EAB8B59778AD9DCAD9FA349@DBBPR08MB5915.eurprd08.prod.outlook.com>
Date: Fri, 11 Jun 2021 06:58:55 -0400
Organization: Reliable Energy Analytics LLC
Message-ID: <1d5d01d75eb0$c7a62b10$56f28130$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_1D5E_01D75E8F.40972320"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGWV7HWN1UFe48pVCqNOvWTpeLidgI50GCWAkrvsgUBigw1latgOsyA
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/3gNNCtJfufe38Rcm2mZkRWZ495A>
Subject: Re: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2021 10:59:06 -0000

+1 “What is a “trustworthy credential” for you? “

And, most importantly from a SCRM perspective, how can a software consumer verify the trustworthiness of a software package, before installation, having only a signed, binary distribution of the software package in hand?

 

 

Thanks,

 

Dick Brooks



Never trust software, always verify and report! <https://reliableenergyanalytics.com/products>  ™

http://www.reliableenergyanalytics.com <http://www.reliableenergyanalytics.com/> 

Email: dick@reliableenergyanalytics.com <mailto:dick@reliableenergyanalytics.com> 

Tel: +1 978-696-1788

 

From: Hannes Tschofenig <Hannes.Tschofenig@arm.com> 
Sent: Friday, June 11, 2021 2:34 AM
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: dick@reliableenergyanalytics.com; Brendan Moran <Brendan.Moran@arm.com>; suit <suit@ietf.org>; Russ Housley <housley@vigilsec.com>
Subject: RE: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

 

Hi Phil, 

 

a few clarifying questions. 

 

*	What is a “trustworthy credential” for you? 
*	Who is the “provider” here? 
*	What do you mean by “Must identify such machines”? Are you saying that the software / firmware update must identity the machine it applies to?
*	When you say “Every software distribution MUST be signed without exception” are you trying to distinguish between the signing the software vs. securing the distribution? With regards to the exception you are not talking about what happens during manufacturing.

 

Ciao

Hannes

 

From: Phillip Hallam-Baker <phill@hallambaker.com <mailto:phill@hallambaker.com> > 
Sent: Friday, June 11, 2021 12:22 AM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com> >
Cc: dick@reliableenergyanalytics.com <mailto:dick@reliableenergyanalytics.com> ; Brendan Moran <Brendan.Moran@arm.com <mailto:Brendan.Moran@arm.com> >; suit <suit@ietf.org <mailto:suit@ietf.org> >; Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com> >
Subject: Re: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

 

I strongly disagree. Given my history of involvement in the WebPKI, I am certainly not biased against CAs. My concern is different.

 

I see multiple concerns:

 

1) Every software distribution MUST be signed without exception

 

2) All software executables and data installed on a machine MUST be signed by the provider.

 

3) All signatures MUST be under keys that have a trustworthy credential.

 

The reason I reject (3) is because I insist on (1) and (2). I want every piece of software to be signed on every machine without any exception whatsoever. That includes every development build, every open source project, every script written by the user. And that should apply to every desktop, laptop, tablet, mobile etc.

 

Thing is that I can't have the strong signing model I want if I also insist that every credential be an EV signature. It is one or the other. I choose everything signed.

 

 

For critical infrastructure devices, I suggest the following:

 

0) Must identify such machines and label them prominently

 

1) Software must be signed under trustworthy credential

 

2) Platform must verify signature before executable is launched.

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.