IETF Last Call Review of draft-ietf-teep-protocol-21
review-ietf-teep-protocol-21-secdir-lc-turner-2025-10-15-00

Hi! Don't be alarmed! This is just my secdir review.

Thanks for a well written document. Comments follow:

0) I ran the I-D Nits and noted there are a lot of out dated references. This
one needs to be updated for sure draft-ietf-rats-eat-31 -> RFC 9711 and the
others are here:

  == Outdated reference: A later version (-34) exists of
     draft-ietf-suit-manifest-33

  == Outdated reference: A later version (-23) exists of
     draft-ietf-suit-mti-09

  == Outdated reference: A later version (-15) exists of
     draft-ietf-suit-report-11

  == Outdated reference: A later version (-12) exists of
     draft-ietf-suit-trust-domains-10

  == Outdated reference: A later version (-09) exists of
     draft-ietf-rats-ar4si-08

  == Outdated reference: A later version (-14) exists of
     draft-ietf-rats-reference-interaction-models-13

  == Outdated reference: A later version (-25) exists of
     draft-ietf-suit-firmware-encryption-23

1) s3: I realize I am being super pedantic, but shouldn’t the success and error
messages be called TEEP Success and Error. The following changes would align
the names of the messages with the CDDL in s4; i.e., drop the “-“ and camel
case it:

   $teep-message-type /= query-request
   $teep-message-type /= query-response
   $teep-message-type /= update
   $teep-message-type /= teep-success
   $teep-message-type /= teep-error

So my suggestion is OLD:

   This specification defines five messages: QueryRequest,
   QueryResponse, Update, Success, and Error.

New:

   This specification defines five messages: QueryRequest,
   QueryResponse, Update, TEEPSuccess, and TeepError.

and then throughout
s/Success/TEEPSuccess
s/Success/TEEPError

2) s4: s/$teep-message-type .within/$teep-message-type within

3) s4: The detailed message specification numbering made me wonder why you
skipped 4 and then also made me wonder why there is no IANA considerations for
registering $teep-type values. Is this in the works? Also, shouldn’t there be
an IANA registry for  data-item-requested, err-code, mapkey, cipher suites
values (non-exhaustive list)?

4) s4.2 & s4.3: The attestation bit is referred to 5 times. Where is that
defined?

5) s4.2: I must be missing something fundamental here, but why is this the case
for challenge in the query-request:

  It MUST be absent if the attestation bit is clear or the
  Passport model is used.

6) s4.2: Maybe add the reference to RFC 9334 here too, it’s in s5.1 too but
this is where “Passport model” first pops up:

   It MUST be absent if the attestation bit is clear or the
   Passport model, see [RFC9334],  is used.

7) s4.3: Maybe add a reference to RFC 9124 for component-id:

  component-id
      A SUIT Component Identifier; see [RFC9124].

8) s5: How is this not an IANA registry entry?

9) s7.1.1: to future proof the document I would drop “(SHA-256 for the ones
mandated in this document)” from bullet 2 and just refer to the profiles. When
you update the profiles then you only need to do it there.

10) s8.1: I just looked at the COSE algorithm registry and -7 (ECDSA w/
SHA-256) and -8 (EdDSA) are both deprecated. I think you’re supposed to be
using -51 (ESP256) and -19 (Ed25519) - based on
https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/

11) s10: There's a lot of good stuff in the SecCons of 9397. Is it worth
referring readers to those SecCons too?

12) s10: crypto: I think maybe some references are necessary to
I-D.ietf-suit-mti for the suit profiles and then maybe IANA entries' references
for -51 and -19 for the crypto suites? I mean what's there now does address the
points, but like people ought to go look at the SecCons for the algorithms
selected.

13) s10: Do you need to say something about randomness for the token?

14) s10: Do you need to say anything (like give a recommendation) for the
lifetime of the token?

15) s11: I would strengthen this:

   If any mechanism
   other than EAT is used, it is up to that mechanism to specify how
   privacy is provided.

to say:

   If any mechanism
   other than EAT is used, that mechanism MUST specify how
   privacy is provided.

Cheers,
spt