Re: [Teep] Genart last call review of draft-ietf-teep-otrp-over-http-13

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: Russ Housley via Datatracker <[e-mail]>
> Sent: Monday, March 28, 2022 10:50 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: Genart last call review of draft-ietf-teep-otrp-over-http-13
> 
> Reviewer: Russ Housley
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.

Thanks Russ for the review!

[...]
> Major Concerns:
> 
> Section 1 says:
> 
>    This document specifies the middle layer (TEEP-over-HTTP), whereas
>    the top layer (TEEP) is specified in [I-D.ietf-teep-protocol].
> 
> I think this should be expanded to provide a reference for the HTTP layer as
> well.  Something like:
> 
>    TEEP implementations MUST support HTTP [RFC9110].

Section 4 already stated: "This document uses HTTP [I-D.ietf-httpbis-semantics] as a transport." which reference is now RFC 9110 so it was already explicit there. However, I have updated section 1 to say:

+ This document specifies the middle layer (TEEP-over-HTTP), whereas
+ the top layer (TEEP) is specified in {{I-D.ietf-teep-protocol}}
+ and the bottom layer (HTTP) is specified in {{!RFC9110}}.

> I realize that this document references I-D.ietf-httpbis-semantics, which talks
> about HTTP/1.0, HTTP/1.1, HTTP/2, and HTTP/3, and it says:
> 
>    All three major versions of HTTP rely on the semantics defined by
>    this document.  They have not obsoleted each other because each one
>    has specific benefits and limitations depending on the context of
>    use.  Implementations are expected to choose the most appropriate
>    transport and messaging syntax for their particular context.
> 
> Therefore, it might appropriate for this document to select a version of HTTP
> for interoperability.

RFC 9205 section 4.1 states:

> Because HTTP is a hop-by-hop protocol, a connection can be handled by
> implementations that are not controlled by the application; for example, proxies,
> CDNs, firewalls, and so on. Requiring a particular version of HTTP makes it difficult
> to use in these situations and harms interoperability. Therefore, it is NOT
> RECOMMENDED that applications using HTTP specify a minimum version of HTTP
> to be used.
>
> However, if an application's deployment benefits from the use of a particular
> version of HTTP (for example, HTTP/2's multiplexing), this ought be noted.
>
> Applications using HTTP MUST NOT specify a maximum version, to preserve the
> protocol's ability to evolve.

Since the middle paragraph case does not apply to TEEP, we follow the RFC guidance above to NOT specify a minimum or maximum version.

[Russ continues:] 
> Minor Concerns:
> 
> The Abstract says: "An implementation of this document can (if desired) run
> outside of any TEE, but interacts with a TEEP implementation that runs inside
> a TEE."  This is a little bit confusing.  I think that it is trying to say that one oc
> the TEEP implementations must be running inside the TEE that is being
> managed by the TAM, but the TAM side on the protocol does not need to be
> implemented in a separate TEE of its own.  I hope that I got that right.  The
> most straightforward clarification might be to add a sentence about the client
> side of the protocol, TEEP "Agent", runs in the TEE that is being managed by
> the TAM.  Please clarify.

I removed the sentence from the abstract since it is not essential in the abstract. The second paragraph of the introduction already gave a better explanation, and to that paragraph I have appended the new sentence:

+ See section 6.2 of [I-D.ietf-teep-architecture] for a depiction of various
+ implementation models.

since that has a figure that is highly relevant here.

> Section 8 should be expanded.  In Section 4, the document says:
> 
>    However, there may be constrained nodes where code space is an issue.
>    [RFC7925] provides TLS profiles that can be used in many constrained
>    nodes, but in rare cases the most constrained nodes might need to use
>    HTTP without a TLS stack, relying on the end-to-end security provided
>    by the TEEP protocol.
> 
> Section 8 ought to discuss this a bit more.  That is, when TLS is not used, what
> are the additional security considerations?

Added:

+ See Sections 4.4.2 and 6 of {{RFC9205}} for more discussion of additional security
+ considerations that apply in this case.

> Nits:
> 
> Section 1, s/A fuller discussion of/A more complete discussion of/

Done.
 
> IDnits reports:
> 
>   -- Possible downref: Normative reference to a draft: ref.
>      'I-D.ietf-httpbis-semantics'
> 
> This document will be published on the standards track, so it will not be a
> downref.

Updated to point to RFC 9110 since the ref is now an RFC.

Latest copy with the above changes is visible at
https://github.com/ietf-teep/teep-over-http/blob/master/draft-ietf-teep-otrp-over-http.md
and I will submit as an updated I-D shortly.

Dave