Trusted Execution Environment Provisioning (TEEP) Protocol
draft-ietf-teep-protocol-26

# Andy Newton, ART AD, comments for draft-ietf-teep-protocol-24
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-teep-protocol-24.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Thanks to the Reviewers

Many thanks to Scott Hollenbeck for the ARTART review, and thanks to the
authors for addressing his comment.

## Comments

I have no objection to the publication of this document as an RFC.

Thanks to Sean Turner for their secdir reviews.

Section 5, second to last para:  Perhaps make this more clear (the sentence is very long).  'and if not then attempt', perhaps 'and if not accepted as trustworthy, then attempt'.  Of course if that is not the intended meaning, then please clarify.

Section 6:  Label 22 appears to be assigned, contrary to the text in para 2.

Section 10, Cryptographic Algorithms:  Please reference RFC9459 here, to explain the use of CTR mode (not an AEAD mode).  Technically, one can get to that RFC via the suit mti draft, but why not reference it explicitly?  

I support both Ketan and Roman's discuss positions.

# Éric Vyncke INT AD comments for draft-ietf-teep-protocol-24
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Other thanks to Eliot Lear, the IoT directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-teep-protocol-23-iotdir-telechat-lear-2026-02-08/ (and I have yet to read a reply from the authors)

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## COMMENTS (non-blocking)

### IoT directorate review and section 4.1.1

As noted above, Eliot did an extensive review and has provided feedback, his points about section 4.1.1 should really be addressed.

### Section 3

Who is the "we" in `we assume them ` ? The authors ? The WG ? The IETF community ? Please avoid ambiguities. 

Possibly also in other places.

### Section 4.2

Why not a MUST in `The TAM SHOULD set an expiration time for each token` ? Also note that guidance must be given if "SHOULD" is kept. See https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ (cfr the guidance/exception given for a SHOULD in section 4.3.1)

### Section 4.2

Please add text about data-item-requested being a registry defined in section 13.3 (which is good idea).

### Section 13.3

Suggest to have at least one code point for "private use" per RFC 8126

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

# WIT AD comments for draft-ietf-teep-protocol-24

Thank you for the work on this document. Thank you to Yoshi for his TSV-ART review. I have no objection to the publication of this document as an RFC, but I do have comments that ought to be easy to address.

## Comments

### Section 3 
A forward reference to Section 11 within Section 3 would have been helpful, e.g., after “The TEEP protocol is transport-agnostic; bindings to	end-to-end security.  TEEP protocol messages are signed by the specific transports are defined in separate companion specifications.”

### Section 10
Is the following text correct and what does that really imply?:
“TEEP is transport	
agnostic; operators MUST ensure the chosen transport provides	
adequate confidentiality, integrity, authentication, and replay	
protection.  See the HTTP binding draft	
[I-D.ietf-teep-otrp-over-http] for transport-specific operational	
details when that binding is used.”

- This seems like an unusual requirement to demonstrate compliance!
-- I’m surprised that the operator would choose the properties of the transport bindings.
- e.g., Is it possible that “operators MUST ensure the chosen transport provides	
adequate confidentiality, integrity, authentication, and replay	
protection” could be removed and replaced by a cross-reference to Section 11, or is something more needed to be explained? 

### Section 11 
Thank you for adding Section 11 in response to that review on “Transport Considerations". This does clarify requirements related to transport protocols and error handling. Although the title word “considerations” might result in these requirements being overlooked whereas this section adds a useful set of requirements.  I suggest the title of this section ought to be changed to indicate that this places requirements on future transport protocol bindings.

# Gunter Van de Velde, RTG AD, comments for draft-ietf-teep-protocol-24

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-teep-protocol-24.txt

# idnits report displays few warnings

# This document is not an easy read (i am not a security expert) and have only performed a high level review. The sections i processed were well written.

# i have only one observation:

19	   This document specifies a protocol that installs, updates, and
20	   deletes Trusted Components in a device with a Trusted Execution
21	   Environment (TEE).  This specification defines an interoperable
22	   protocol for managing the lifecycle of Trusted Components.

GV> The abstract says that it defines an interoperable protocol. Is that not implicit when a protocol is used by different devices? Maybe my question is what does 'interoperable' describe in the context of the abstract?

What about the following abstract (AI generated)

"
   This document specifies the Trusted Execution Environment Provisioning
   (TEEP) Protocol, which enables secure lifecycle management of Trusted
   Components in devices with a Trusted Execution Environment (TEE).
   The protocol defines message exchanges between a Trusted Application
   Manager (TAM) and a TEEP Agent to query device state, convey
   attestation evidence, and install, update, or delete Trusted
   Components.  Messages are encoded in CBOR and secured using COSE.
"

Many thanks for this document,

Kind Regards,
Gunter Van de Velde

Thanks to the authors and the WG for their work on this document.

Also, thanks for the updates to address the points in my previous DISCUSS ballot in v26.

However, here are a few comments/suggestions on the updated text in v26:

1) Please fix the section references:
The registries in Sections 13.2 through 13.6 are to be created within this registry group.

2) On the DE guidance.
The request does not conflict with active IETF work in related areas.

I assume this needs to be qualified as "When the request is coming from outside of the IETF, ..."? 

3) I would urge the authors and the WG to reconsider whether they wanted to expand the Standards Action range and perhaps do a 50-50% split between Standards Action and Specification Required. I get the impression that the Specification Required is meant to mainly cater to allocations from outside the IETF and if so, please consider whether the range for IETF is sufficient and if any such range preferences are required to be spelled out in the registry or in DE guidance. Obviously I don't know enough about this work to say anything further - so, this is just a point for your consideration.

Hi Hannes, all,

All my comments in my previous ballot [1] are addressed in [2]. Thank you.

I noticed the following when checking the new version:
(27/02 Update: all these were addressed by Hannes in https://author-tools.ietf.org/iddiff?url1=draft-ietf-teep-protocol-24&url2=draft-ietf-teep-protocol-25&difftype=--html) 

# Broken heading: OPS section is a separate section, not a subsection of sec section 

OLD:
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  49
     10.1.  Operational Considerations . . . . . . . . . . . . . . .  51

NEW:
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  49
   11.  Operational Considerations . . . . . . . . . . . . . . .  51

# 0 is a reserved/not allowed type value

CURRENT:
   ; message type numbers, in one byte which could take a
   ; number from 0 to 23
   $teep-type /= (0..23)

I would align the CDDL with the intended usage. Having a mention that 0 is reserved and MUST NOT be used would be sufficient.

# Inconsistency

Some text clean-up is needed here as its says contradicting things:

CURRENT (4.6):
   err-code
      The err-code parameter contains one of the error codes listed
      below.  The value 0 is reserved and MUST NOT be used.  Only
      selected values are applicable to each message.  Note that error
      codes are restricted to the range (0..23) to permit encoding as
      single-byte CBOR unsigned integers.  Error code values 0, 11-16,
      and 18-22 are currently unassigned and reserved for future use.
      Error code 0 is intentionally reserved to prevent accidental use.

NEW:
   err-code
      The err-code parameter contains one of the error codes listed
      below.  The value 0 is reserved and MUST NOT be used.  Only
      selected values are applicable to each message. Error code values 11-16,
      and 18-22 are currently unassigned and reserved for future use.

# Specification Required policy: Missing Guideline for DEs

You have several ranges that are governed by Specification Required policy. That policy involves experts per rfc8126#section-4.6:

   For the Specification Required policy, review and approval by a
   designated expert (see Section 5) is required, and the values and
   their meanings must be documented in a permanent and readily
   available public specification, in sufficient detail so that
   interoperability between independent implementations is possible.
   This policy is the same as Expert Review, with the additional

Some guidance to help DEs perform reviews would be needed here per rfc8126#section-4.5:

   The required documentation and review criteria, giving clear guidance
   to the designated expert, should be provided when defining the
   registry.  It is particularly important to lay out what should be
   considered when performing an evaluation and reasons for rejecting a
   request.  It is also a good idea to include, when possible, a sense
   of whether many registrations are expected over time, or if the
   registry is expected to be updated infrequently or in exceptional
   circumstances only.

# Guidance for authors/experts/IANA?

Section 13.6 says:

   Any new cipher suites MUST provide authentication, integrity, and
   SHOULD provide confidentiality protection.

The normative requirements can be moved to the main body of the spec. You formulate it as a guidance for DEs.

Please check “Inappropriate Uses of Key Words” in https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ for the matter.

# Add RFC 8792 to your references as that is needed to unfold the examples.

CURRENT:
CBOR Diagnostic Notation of SUIT Manifest

   =============== NOTE: '\' line wrapping per RFC 8792 ================

You may add the following at the end of your section 2:

NEW:
  Examples are folded following the conventions in [RFC8792].

# Replace teep-success with success (3 occurrences)

CURRENT:
D.5.1.  CBOR Diagnostic Notation

   / teep-success = /
   [
     / type: / 5 / TEEP-TYPE-teep-success /,
     / options: /
     {
       / token / 20 : h'A0A1A2A3A4A5A6A7A8A9AAABACADAEAF'
     }
   ]

D.5.2.  CBOR Binary Representation

   82                  # array(2)
      05               # unsigned(5) / TEEP-TYPE-teep-success /
      A1               # map(1)
         14            # unsigned(20) / token: /
         50            # bytes(16)
            A0A1A2A3A4A5A6A7A8A9AAABACADAEAF

# Replace teep-error with error (3 occurrences)


CURRENT:
D.6.1.  CBOR Diagnostic Notation

   / teep-error = /
   [
     / type: / 6 / TEEP-TYPE-teep-error /,
     / options: /
     {
       / token / 20 : h'A0A1A2A3A4A5A6A7A8A9AAABACADAEAF',
       / err-msg / 12 : "disk-full"
     },
     / err-code: / 17 / ERR_MANIFEST_PROCESSING_FAILED /
   ]

D.6.2.  CBOR binary Representation

   83                  # array(3)
      06               # unsigned(6) / TEEP-TYPE-teep-error /

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-teep-protocol-23&url2=draft-ietf-teep-protocol-24&difftype=--html 

[2] https://mailarchive.ietf.org/arch/msg/teep/EtIwDcTHKHxr0y8-6xUzAdMY8RQ/

Thank you to Paul Kyzivat for the GENART review.

Thank you for addressing my DISCUSS and COMMENT feedback.

Congrats to the WG on completing this core protocol specification.