[Teep] Éric Vyncke's Yes on draft-ietf-teep-architecture-18: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-teep-architecture-18: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teep-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-teep-architecture-18
CC @evyncke

Thank you for the work put into this document. I really like the approach
(except perhaps the role of TEEP broker).

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

Please note that Ines Robles (iot dir) and Bob Halley (int dir) have also
reviewed the I-D at my request (thank you both !). I would appreciate it if you
considered their reviews as mine (including replying by email to their reviews):

*
https://datatracker.ietf.org/doc/review-ietf-teep-architecture-18-iotdir-telechat-robles-2022-09-04/
(esp for her point about RFC 7228 classification) *
https://datatracker.ietf.org/doc/review-ietf-teep-architecture-18-intdir-telechat-halley-2022-08-27/
(esp for his point about section 4.1, thanks Ming for your reply)

Special thanks to Tiru Reddy for the *one-year old* shepherd's write-up
including the WG consensus but missing the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Role of TEEP Broker

After reading the I-D, I am still a little unclear about the role of the TEEP
Broker ? Is it simple a store/forward cache ? I.e., it does not authenticate to
any party and does not have any access to any message? If so, it would be nice
to say so early in the text (before section 5 when my own penny dropped) and
perhaps rename it in 'TEEP relay'.

### Section 1
```
   In a system with multiple TEEs, this also means
   that code in one TEE cannot be read or tampered with by code in
   another TEE.
```
Should this rather be `code and data in one TEE` ?

To be honest, this is the first time I read 'Rich Execution Environment';
should there be some explanations (shorter than the one in the terminology
section)? How different is it from the 'commodity operating system' (used in
the paragraph above).

### Section 2 physical only ?

`Device: A physical piece of hardware`... I would have guessed that a TEE could
exist in a virtual machine provided that the hypervisor offers the same
'physical' security as the HW. I.e., TA in the VM could be 'isolated' from
other untrusted app in the same VM. See also section 3.4 and the cloud use case.

### Section 2 no TEE definition ?

A lot of terms are nicely and clearly defined, but 'TEE' itself is not defined.

### Section 2 only TA in TEE ?

The definition of 'TA' implies that it runs in a TEE, but are there only TA
running in TEE ?

### Section 4.1 TEEP broker is not trusted ?

Should the TEEP broker itself run in a TEE ? Of course, this is chicken and
egg...

### Section 4.1 CA

Nothing dramatic, but the role of a CA is explained in the text while there is
no CA in fig 1

### Section 4.4.1 reference

Should there be an informative reference about SGX ?

### Section 4.5 wrong direction ?

Is the arrow (step 4) in the wrong direction as this is up to the TEEP broker
to contact the TAM per previous text? or add a similar text as in step 3.

### Section 5.4 and constrained devices

As PKI cert chains can be very long, should there be some text about
constrained devices/networks where several kBytes are too many ? Even if only
to say 'TEEP is not usable on constrained networks/devices' ?

### Section 9.3

While I do not contest that REE can be compromised, I think that claiming
`billions of compromised devices` is too many and should require a reference.

### Section trusting time

As PKI relies on correct time information and as some devices relies on NTP,
GSM, GNSS, ... time information and as those can be spoofed, should there be a
sub-section on time attack ? (this would be a DoS or allowing the use of an old
- compromised - TA / trust anchor).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments