HTTP Transport for Trusted Execution Environment Provisioning: Agent Initiated Communication
draft-ietf-teep-otrp-over-http-15

# Internet AD comments for draft-ietf-teep-otrp-over-http-14
CC @ekline

## Comments

### S5.6, S6.4

* Is there any discussion that can be referenced for how to set "reasonable"
  timeouts?  Even though the HTTP transport layer may be up and functioning,
  how long is too long to wait for message processing before an error should
  be declared by one of the layers?

  I'm sure the timeout needs might vary according to many different factors,
  but does the desired timeout need to be conveyed by some mechanism to the
  TEEP/HTTP {Client,Server} layer?

## Nits

### S7

* Item 1: s/cient/client/

# AD Review of draft-ietf-teep-otrp-over-http-14
cc @fpalombini

Thank you for the work on this document.

Many thanks to Carsten Bormann for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/XCL1Bpk7GLkeoJ4NM2jzbhw2aJA/. I note that a few of Carsten's comments have made it to v-14, although I didn't find any reply to his email. In particular, I agree with Carsten on the SHOULD in section 6.2, see my third point below.

## Comments

### Reference to 9205 4.4.2 for security considerations

Section 4:
> See Sections 4.4.2 and 6 of [RFC9205] for more discussion of additional security considerations that apply in this case.

Which part of 4.4.2 of 9205 is relevant here?

### Update BCP195 reference

Section 4:
> See [BCP195] for additional TLS recommendations and [RFC7925] for TLS recommendations related to IoT devices.

The BCP195 reference should be updated to point to 9325, which obsoletes 7525

### SHOULD be 204

Section 6.2:
> If the TAM passes back an empty buffer, the TEEP/HTTP Server sends a successful (2xx) response with no body. It SHOULD be status 204 (No Content).

As Carsten asks, what alternative to 204 is there? What would be the reason to deviate from the SHOULD?

## 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

Thanks for this document. There was one thing in the introduction which rubbed me the wrong way. I acknowledge that this is probably due to a defect in my personality, but I thought I'd flag it and you can address it or disregard it as you please.

The sentence in question is,

   There are two topological scenarios in which TEEP could be deployed:

The quoted sentence implies that the list (Agent behind NAT/firewall, TAM behind NAT/firewall) is exhaustive. But surely both TAM and Agent on the open Internet would work too? 

For that matter, there's a large body of work (in which I am not at all expert) that aims to accommodate both client and server being behind a NAT or firewall. I assume you don't want to go to the additional labor to cater for this scenario, and therefore it really is one in which TEEP could *not* be deployed.

Thanks to Carsten Bormann for the ARTART review.

The shepherd writeup confirms that Proposed Standard is the requested status, but doesn't indicate why that was chosen.  (It's fairly clear that this is a protocol or even an applicability statement, but a sentence or two about that would be great to include.)  The shepherd writeup is also substantially dated; it's from mid-2021, and mentions a sponsoring AD who is no longer on the IESG.

Section 1 is "Introduction" yet makes a normative ("SHOULD") assertion, which is peculiar.  If this is a new assertion, it should be in its own later section; if it's imported from another TEEP document, I suggest expressing it some other way ("generally required" or suchlike) so that this document isn't seen as the normative one on this point.

The SHOULD near the top of Section 3 is bare, in the sense that it presents a choice to implementers but no guidance about when it might be legitimate to deviate from the recommended behavior.  I suggest adding at last a brief discussion of this.  (At least I presume this is a new SHOULD; at first I read this as if it's importing a SHOULD from Section 4.13 of RFC 9205, but there's no SHOULD in that section.)

I have similar comments about the SHOULD in Section 6.2.  What if I use some other response code?

I have the same question as Erik about timeouts.

Thank you to Stefan Santesson for the SECDIR review.

** Section 5.  Starting in this section there is the introduction of the concept of “message buffers” being exchanged.   Is there some more formal description of that idea in this context.  I didn’t find that term defined in draft-ietf-teep-protocol or draft-ietf-teep-architecture.

** Section 8.  The protocol interaction model has URI being exchanged and followed.  Consider providing a reference to Section 7 of RFC 3986 to provide generic guidance about de-referencing URIs.

Thanks for working on this specification. I haven't find any TSV related issues in this specification in my review. 

I have comments/questions that I believe would improve the document if addressed -

# it says -

   and a "Trusted Application Manager (TAM)" on the server side) SHOULD themselves run inside a TEE

  why is it necessary to use normative language here? is this something this spec describing first for the TEEP architecture? It is however not the intention of this specification to define TAM placement, or?


# it says -

     Since POST responses without explicit freshness information are uncacheable (see Section 9.3.3 of [RFC9110]), no Cache-Control header is needed.

  Should this not say - 

     Since POST responses without explicit freshness information are uncacheable (see Section 9.3.3 of [RFC9110]), hence Cache-Control header MUST NOT be used.

  I.e. use normative language to avoid the use of that particular header? also explains if a Cache-Control header would generate error.