Re: [Teep] I-D Action: draft-ietf-teep-protocol-09.txt

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 30 July 2022 23:48 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01179C14F74F for <teep@ietfa.amsl.com>; Sat, 30 Jul 2022 16:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIqD60ks03nL for <teep@ietfa.amsl.com>; Sat, 30 Jul 2022 16:47:55 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2C0C14CF05 for <teep@ietf.org>; Sat, 30 Jul 2022 16:47:55 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [75.98.19.153]) by relay.sandelman.ca (Postfix) with ESMTPS id 2CC5A1F448 for <teep@ietf.org>; Sat, 30 Jul 2022 23:47:53 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id BAA0D1A01D3; Sat, 30 Jul 2022 19:47:47 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: teep@ietf.org
In-reply-to: <165758069576.5292.17995718687189976942@ietfa.amsl.com>
References: <165758069576.5292.17995718687189976942@ietfa.amsl.com>
Comments: In-reply-to internet-drafts@ietf.org message dated "Mon, 11 Jul 2022 16:04:55 -0700."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 30 Jul 2022 19:47:47 -0400
Message-ID: <701168.1659224867@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/a3WCIWhl5hBFMllZSMx7aIqkrF0>
Subject: Re: [Teep] I-D Action: draft-ietf-teep-protocol-09.txt
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jul 2022 23:48:00 -0000

I took a look through draft-ietf-teep-protocol.
This might be my first reading in a long time.
I'm sorry I missed the WG session... conflicts.
I did my annotations here, which might be amusing for some:
  https://hyp.is/go?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-teep-protocol-10.html&group=__world__

I'd send issues/PRs, but I didn't find a venue for the document.

section 4.2:
} The TAM SHOULD set an expiration time for each token and MUST ignore any
} messages with expired tokens. The TAM MUST expire the token value after
} receiving the first response containing the token value and ignore any
} subsequent messages that have the same token value.

I guess this is a defense against replays.
I guess this document hasn't told me if it's over HTTP or carrier pigeon yet :-)
How does the TAM know that the *first* isn't invalid?
I guess it has already validated the message, so it must be okay.
This isn't a replay window here.  Some motivation for what attack we are
resisting here would be good.

section 4.3:
} The absence of this parameter indicates that the format is "application/eat-cwt;
} profile=https://datatracker.ietf.org/doc/html/draft-ietf-teep-protocol-10
} (RFC-editor: upon RFC publication, replace URI above with
} "https://www.rfc-editor.org/info/rfcXXXX" where XXXX is the RFC number of
} this document.) It MUST be present if the attestation-payload parameter is
} present and the format is not an EAT in CWT format with the profile defined
} below in Section 5.

If we revise this document rfcXXXX-bis, then what will the absense of the payload format mean?
It feels like premature optimization to set a default here.
I think that the profile should always be present, or never present.

section 4.3.1:
} When an Entity Attestation Token is used

… and when EAT is not used?
There are quite a number of places where the document says "when EAT..." and
to me they read like stealth SHOULDs.   I understand that the document wants to
enable other attestation systems other than EAT, and I'm okay with that.
I'm not sure what to suggest, but it feels like a documentation bug.

such as:
 section 5:
 } While the TEEP protocol does not require use of EAT, use of EAT is
 } encouraged and Section 4.3

 mcr: Need to list alternatives and reasons not to use EAT.


section 4.4:
} It can also be used to pass a successful Attestation Report back to the
} TEEP Agent when the TAM is configured as an intermediary between the TEEP
} Agent and a Verifier, as

this is another case where I think "when" is being used when SHOULD ought to
be used.  Then it would be obvious that there is a case "when the TAM is not
configured", and why would someone do A or ~A here?

section 4.4.1:
} Example 1: Having one SUIT Manifest pointing to a URI of a Trusted Component Binary

I don't like them being called examples. They aren't things I can ignore.
I think that they are usage scenarios, and there seem to be four important
ones.

section 4.4.1:
} The device must fetch the Trusted Component Binary in another connection
} after receiving an Update message

I'd add an additional CON, and bring it up in Privacy Consideration.
  The device must reveal eis location to the Trusted Binary server.

section 6:
} Since the word "key" is mainly used in its other meaning, as a
} cryptographic key, this specification uses the term "label" for this usage as
} a map key.

Is this something that EAT should say?

section 7.1.2:
} Hence, depending on the freshness mechanism in use, the TAM may need to
} store data (e.g., a nonce) for some time.

This also suggests that for mobile devices that it may be hours to days
before before right things are installed if they require unmetered WIFI to
get the right pieces. The mobile device might change IP addresses and even
geographies.

(I was thinking based upon some travel in 2019 that someone with a mobile
device in some restrictive localities may find they have to change to their
roaming SIM card in order to appear in their "home" country, at which point
they might even wind up with a different set of requirements)

I'm also concerned about the number of dependancies upon other documents in
other WGs that do not seem at all close to completing.  The dependancy graph
might be useful, and "you" TEEP folks might have to organize interventions in
other WGs to get documents advanced!



--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-