Re: [T2TRG] changes to richardson-t2trg-idevid-considerations

Carsten Bormann <cabo@tzi.org> Sun, 11 April 2021 20:43 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805913A1D73 for <t2trg@ietfa.amsl.com>; Sun, 11 Apr 2021 13:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 c251Gf7b9nLN for <t2trg@ietfa.amsl.com>; Sun, 11 Apr 2021 13:43:47 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7E93A1D72 for <t2trg@irtf.org>; Sun, 11 Apr 2021 13:43:47 -0700 (PDT)
Received: from [192.168.217.118] (p548dc178.dip0.t-ipconnect.de [84.141.193.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FJP3M6t6Kz10Bt; Sun, 11 Apr 2021 22:43:43 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <18353.1613952243@localhost>
Date: Sun, 11 Apr 2021 22:43:43 +0200
Cc: t2trg <t2trg@irtf.org>
X-Mao-Original-Outgoing-Id: 639866622.435517-53b6cd9f76c5e5203b731dfd9e500442
Content-Transfer-Encoding: quoted-printable
Message-Id: <17615184-3961-4019-9F92-093AF4E925D5@tzi.org>
References: <18353.1613952243@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/e-zob2Z4zWdLcB9t25Fis1Gme0I>
Subject: Re: [T2TRG] changes to richardson-t2trg-idevid-considerations
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Thing-to-Thing Research Group <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Apr 2021 20:43:50 -0000

I finally managed to have a look at -03.
(Hey, I should be doing AUTH48, too :-)

# Comments

I still think that any discussion of TrAncs/Identities needs to be accompanied by a discussion of the authorizations associated with them.  Many of the keys that are discussed are implicitly tied to a specific authorization (e.g., second-level bootloader).  But where keys can be added/removed (and not just replaced), it is very important that they are added with the right authorizations.
E.g., section 3 discusses type of TrAncs, but in terms of their protection, not in terms of their semantics/the authorization implied by a proof of their possession.

Do we want to discuss Roots of Trust?  And their relationship to Identities?

We probably want to introduce a term such as “shielded” for keeping keys under special protection.

The whole issue of time-limited certificates vs. device lifetimes probably needs more discussion (as well as recovery strategies).

Involuntary ownership transfers should at least be mentioned.

A key can have more than one cert (e.g., intro to Section 4).

The issue of lack of (reliable real-time) communication between the manufacturing environment and the initial device owner (“manufacturer”) probably needs some discussion (and some more motivation, as it tends to keep people in an incredulous state of mind).

The term “birth certificate” is a nice pun; can we use it some more?

# Minor

I didn’t check whether this statement is strictly true:

           The device identity certificate is also
           used to sign Evidence by an Attesting Environment (see
           [I-D.ietf-rats-architecture]).

(i.e., no other key can be used than that of the device identity certificate).

This is also an example for a regression where “certificate” is used but “private key associated with the public key of the certificate” is meant.  I understand that this lends some brevity, but identifying “the policeman that investigates a murder” by “the killer” also is shorter.

ISO 14000 is a family of standards related to environmental management that exists to help organizations minimize how their operations negatively affect the environment; comply with applicable laws, regulations, and other environmentally oriented requirements; and continually improve in the above [Wikipedia].
(Did you mean ISO 27000?)

Should we have a term for “private or symmetric key”?  “Secret key” maybe?
(OK, that is often used as synonym for “private key” that doesn’t alliterate with “public key”.)

# Nits

There are a few references that probably would benefit from anchoring them in the text:

[pelionfcu]
[nistsp800-57]
[JTAGieee]
[rootkeyrollover]

Having some references for TPM would help.
As would a brief discussion of secured vs. measured boot.

Some boring nits are in PR https://github.com/mcr/idevid-security-considerations/pull/3 .

Grüße, Carsten