[Teep] AD review of draft-ietf-teep-otrp-over-http-12

[Benjamin Kaduk <[e-mail]>]

This is also in good shape, modulo §5.2, and will want a new I-D before
IETF Last Call.

-Ben

It's possible that some of these topics might be more properly addressed in
the architecture doc than here; I didn't put a huge amount of thought into
that division, and trust that the author overlap will help make the right
thing happen.

I put some editorial nits in
https://github.com/ietf-teep/otrp-over-http/pull/34

Section 4

   When HTTPS is used, clients MUST use the procedures detailed in
   Section 6 of [RFC6125] to verify the authenticity of the server.  See

The RFC 6125 procedures rely on the consuming specification to provide a
couple more inputs to the procedure.  In particular, the client needs to
have a list of acceptable reference identifiers, and protocols using the RFC
6125 procedures usually will say that the client needs to match against a
particular type of name (I would expect DNS-ID here), and how to obtain the
specific name to use for a given interaction.  In this case, the DNS-ID
would probably be obtained from the authority component of the TAM URI ...
which is basically the same procedure described in
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics#section-4.3.4
.  So we might consider using that as the primary reference, mentioning that
it incorporates the RFC 6125 procedures but not directly incorporating the
RFC 6125 procedures ourselves.

   [BCP195] for additional TLS recommendations and [RFC7925] for TLS
   recommendations related to IoT devices.

I note that both RFC 6125 and RFC 7525 (BCP 195) have active "bis" drafts in
UTA.  If I remember correctly, some of the 6125bis changes are "big", but
even so, we would likely want to pull in the updated versions if they are
available by the time we are ready for publication, with the caveat that if
we defer to httpbis-semantics, that would take precedence.  (Since we'll be
waiting for draft-ietf-teep-protocol, it's a little hard to predict exactly
when that will be.)

Section 5.1.1

   If the TEEP Agent passes back a TAM URI with no message buffer, the
   TEEP/HTTP Client attempts to create session state, then sends an
   HTTP(S) POST to the TAM URI with an Accept header with the TEEP media
   type requested, and an empty body.  [...]

I'm having a bit of trouble around "with the TEEP media type requested", as
it seems to imply that the TEEP Agent has requested a specific media type,
and that media type request needs to be propagated through to the TAM.  But
in the previous section we only talked about a TAM URI being passed back,
not a TAM URI and some other (meta)data.  This makes me wonder if we're just
saying "populate the Accept header field with the single media type
application/teep+cbor", since that's the single defined media type for TEEP.
But elsewhere in the document we seem to be careful about providing
flexibility about what media type is in use.

Section 5.2

This section overall seems kind of incohesive.  It's supposed to be about
what to do when an application tells a broker that a previously installed TA
is not needed anymore; an "uninstall request", as it were.  But then we go
on to say:

   *  Optionally, any requirements that may affect the choice of TEE, if
      multiple are available to the TEEP Broker.

and

   When a TEEP Broker receives such a notification, it first identifies
   in an implementation-dependent way which TEE (if any) is appropriate
   based on the constraints expressed, as in Section 5.1.

that talk about picking a TEE in the same way we would for an installation,
as if there is no advance knowledge that the TA is already installed in some
specific TEE.  Now, it may not be feasible for the broker to track state on
which TA is installed in which TEE at behest of which rich application, so
we probably can't just say "use the TEE that had this TA installed due the
request of this rich application", but we could frame the discussion to
acknowledge that there *is* some single TEE that has the copy of the TA that
we're trying to uninstall, and we're trying to use as reliable a procedure
as possible to direct the uninstall-request to the right TEE.  So, instead
of the above, we might refer to any requirements "that would have affected
the choice of TEE to originally install the TA into" and having the broker
identify "which TEE is believed to contain the TA in need of
uninstallation".

   The TEEP/HTTP Client then informs the TEEP Agent in that TEE by
   invoking an appropriate "UnrequestTA" API that identifies the
   unneeded TA.  The TEEP/HTTP Client need not know whether the TEE
   actually has the TA installed.

We also jumped from the TEEP Broker to the TEEP/HTTP Client, here, whereas
in §5.1 we had the Broker delegate the action to "the TEEP/HTTP Client for
that TEE".  We should probably have a similar transition in this section.

   The TEEP Agent will either (a) pass no data back, (b) pass back a TAM
   URI to connect to, or (c) pass back a message buffer and TAM URI to
   send it to.  The TAM URI passed back may or may not be the same as
   the TAM URI, if any, provided by the TEEP/HTTP Client, depending on
   the TEEP Agent's configuration.  If they differ, the TEEP/HTTP Client
   MUST use the TAM URI passed back.

This looks like just a copy/paste of the text from §5.1 ... but we didn't
mention the possibility of getting a TAM URI from the application installer
in this section, so (b) feels out of place without such a previous lead-in.

   Processing then continues as in Section 5.1.1.

I might consider (but might not end up actually) mentioning here that we
still have to create session state even for the UnrequestTA action, since
the session state relates to an ongoing/active TEEP Agent/TAM exchange, and
is not persistent during normal TA operation.

Section 5.3

   When a TEEP Agent passes a message buffer (and TAM URI) to a TEEP/
   HTTP Client, the TEEP/HTTP Client MUST do the following, using the
   TEEP/HTTP Client's session state associated with its API call to the
   TEEP Agent.

As written, this only covers case (c), but I'm inferring that we intend for
it to also cover case (b).  In order to cover case (b) as well as case (c),
we'd need to not require that a message buffer is passed back (or at least,
clarify that this buffer might be empty), and could instead talk about the
client having an outstanding HTTP request (which might entail pushing the
construction of the request back into an earlier section in the "got a
message buffer" case).

   The TEEP/HTTP Client sends an HTTP POST request to the TAM URI with
   Accept and Content-Type headers with the TEEP media type in use, and
   a body containing the TEEP message buffer provided by the TEEP Agent.
   The HTTP request is then associated with the TEEP/HTTP Client's
   session state.

The Content-Type requirement is already in place for responses due to the
text in §4.  It seems like we might incorporate the requirements on HTTP
requests into that section (which, after all, is "Use of HTTP as a
Transport") and avoid repeating them here.

Section 5.6

   If any HTTP request results in an HTTP error response or a lower
   layer error (e.g., network unreachable), the TEEP/HTTP Client calls
   the TEEP Agent's "ProcessError" API, and then deletes its session
   state and informs its caller of a failure.

The lower-layer errors are often very unauthenticated (e.g., ICMP), and in
some scenarios we see guidance to not act on such signals *immediately*, to
give a competing successful response a chance to arrive.  But I'm okay
classifying such behavior as "quality of implementation" and leaving this
text unchanged.

Section 6

It seems like there needs to be some out-of-band agreement between TAM and
TEEP/HTTP server as to what media type(s) are supported.  That is probably
worth mentioning somewhere, though I'm not sure if this is quite the best
place to do so.

Section 6.1

   If the TAM does not receive the appropriate Content-Type header
   fields, the TAM SHOULD fail the request, returning a 415 Unsupported
   Media Type response.  Similarly, if an appropriate Accept header
   Media Type response.  Similarly, if an appropriate Accept header
   field is not present, the TAM SHOULD fail the request with an
   appropriate error response.  [...]

I just want to confirm that "SHOULD" is the right requirements level here.
I do see that §4.13 of BCP56bis only indicates a need to require *clients*
to fail on the wrong Content-Type, and this section applies to the server,
so we may not want/need to have a hard requirement.

   When an HTTP POST request is received with an empty body, the TEEP/
   HTTP Server invokes the TAM's "ProcessConnect" API.  The TAM will
   then pass back a (possibly empty) message buffer.

I'm a little confused at when the resulting message buffer would be empty,
as the ProcessConnect API appears to exist in order to create a session so
that TEEP Agent and TAM can communicate.  At this point we don't have any
information at all about which TEEP Agent is initiating the session, and
thus it seems premature to make a conclusion that this TAM has nothing
further to say to that TEEP Agent.  Would the empty buffer only result in an
error or execption case, e.g., if the TAM was shutting down?  (I recall that
the empty buffer will be treated by the TEEP/HTTP Client as a signal to
destroy session state and make not further requests to that TAM.)

Section 8

A few more topics that we might want to cover in these security
considerations:

Part of the design/requirements is a periodic check for policy changes
(§5.5); the listed options here all seem to place the Broker or TEEP/HTTP
client in the critical path for the policy-check workflow.  Since these are
(to some extent) untrusted components, we could talk about the possibility
for the periodic policy check to be missed, what risks that exposes the
TEE/TAs to, and perhaps mention that there are countermeasures available to
the TEEP Agent (with caveat that a "dead-man's switch" would give no service
rather than vulnerable service and be subject to DoS attack).

Similarly, the Broker as an untrusted component is involved in the mechanics
of installing new TAs.  It might be worth reiterating that the authority for
what TAs are running in a given TEE is assigned amongst the TEEP Agent and
the TAM, and while the Broker can in effect "make suggestions", it doesn't
actually decide or enforce what runs where.  (Modulo the ever-present DoS
risk, of course.)  In contrast to the previous point, the Broker does seem
to have full control over which TEE a given installation request is directed
at, and there might be some security considerations relating to how the
broker picks amonst multiple TEEs to try to use.

The authorization model for the UnrequestTA operation is quite weak, with
essentially any untrusted application in the rich execution environment
being able to request the operation.  We might be able to do something
vaguely like a "capability URL" where the "unique identifier of the TA" is
hard to guess and acts as a bearer token, but I don't think the architecture
allows anything better.  I don't have a great sense for what
countermeasures are available to respond to a (successful) malicious
UnrequestTA operation; the main thing that comes to mind is to have the
application in the rich execution environment that still needs the TA to
notice its absence and request it back, but there are probably others,
possibly even within the TEEP Agent or TAM.