[Teep] AD review of draft-ietf-teep-architecture-15

[Benjamin Kaduk <[e-mail]>]

Overall this is in pretty good shape, but we'll want a new I-D before going
to IETF Last Call.

-Ben

The shepherd writeup only answers the first part of item (1); there are two
more questions to answer.

I'm not entirely sure if this is better addressed in the architecture doc or
the HTTP transport doc, but it seems to me that the "ProcessConnect" API is
not really described well in either doc (in particular, why there's a need
for it as a distinct option from ProcessTeepMessage).  It may be that the
concept of a "connect"ion is what we really want to explain, especially in
terms of its relationship to a "session" (as discussed in the HTTP transport
doc).

I put some editorial nits in
https://github.com/ietf-teep/architecture/pull/231

Section 1

                                                           In this TEE
   ecosystem, there often arises a need for an external trusted party to
   verify the identity, claims, and rights of TA developers, devices,
   and their TEEs.  This trusted third party is the Trusted Application
   Manager (TAM).

Do users or device owners have any rights that need to be enforced?  Can the
TAM do that?

If the need only "often arises", that implies there are some instances where
the need is not present.  We might want to say that our architecture always
has a TAM and make some remark about that not being very disruptive for the
rare cases where there is no specific need for a TAM, as the entity
provisioning the TA software could still run a TAM of their own and be able
to use the TEEP protocol.

Section 2

   -  Rich Execution Environment (REE): An environment that is provided
      and governed by a typical OS (e.g., Linux, Windows, Android, iOS),
      potentially in conjunction with other supporting operating systems
      and hypervisors; it is outside of any TEE.  [...]

At risk of being overly pedantic, "outside of any TEE" is a global/universal
statement, which would seem to rule out some sort of "hierarchical" setup
where (e.g.) a VM runs in a hypervisor-scale TEE and has individual smaller
TEEs running inside of it.  If we instead said something like "outside of
the TEEs managed by the TEEP protocol" that would match up more directly
with the natural protocol scope.

   -  Trust Anchor: As defined in [RFC6024] and
      [I-D.ietf-suit-manifest], "A trust anchor represents an
      authoritative entity via a public key and associated data. The
      public key is used to verify digital signatures, and the
      associated data is used to constrain the types of information for
      which the trust anchor is authoritative."  The Trust Anchor may be
      a certificate or it may be a raw public key along with additional
      data if necessary such as its public key algorithm and parameters.

Our definition of raw public key (especially after my proposed edits)
includes the algorithm and arguably its parameters as well, so this "such
as" phrase doesn't seem to be adding much value.

Section 4.1

      A TAM may be publicly available for use by many Trusted Component
      Signers, or a TAM may be private, and accessible by only one or a
      limited number of Trusted Component Signers.  It is expected that
      many manufacturers and network carriers will run their own private
      TAM.

Might enterprises run their own TAM as well?

      Any entity is free to operate a TAM.  For a TAM to be successful,
      it must have its public key or certificate installed in a device's
      Trust Anchor Store.  [...]

(probably editorial) We're slightly inconsistent about whether we always
include the "or a certificate it chains up to" in the Trust Anchor Store.
Personally I'm not terribly concerned about it, though some future reviewers
may disagree.

Section 4.3

   As shown in Figure 2, a TEEP Broker provides communication between
   one or more TEEP Agents and one or more TAMs.  The selection of which
   TAM to communicate with might be made with or without input from an
   Untrusted Application, but is ultimately the decision of a TEEP
   Agent.

There is perhaps some subtlety in what we mean by "communicate with" -- a
broker could go off and send network packets to arbitrary TAMs, but the TEEP
Agent controls whether or not to act on messages/requests from each TAM.
So maybe the final clause could be "but it is ultimately the decision of a
TEEP Agent which TAM(s) to interact with" or similar.  To be clear, it's
probably also fine to leave it as-is.

Section 4.4

   There are three possible cases for bundling of an Untrusted
   Application, TA(s), and Personalization Data:

This seems to be making some assumptions -- I count five possible ways to
partition three items into one or more groups (one way with one group, one
way with three groups, and three ways with two groups).  While it may not
make much sense to bundle the Untrusted Application and Personalization Data
together without the TA(s), or bundle the TA(s) and Personalization Data
together without the Untrusted Application, I'm not sure that we should
silently discard those possibilities.

Section 4.4.1

   Untrusted Application in a trusted fashion.  Finally, the
   Personalization Data would need to be sent out of the TEE (encrypted
   in an SGX enclave-to-enclave manner) to the REE's installation app,

I'm not entirely sure that I have connected all the pieces that would
require the enclave-to-[other-]enclave encryption here -- is it because the
decryption of the bundled program happens in the TEEP Agent and the
personalization data has to get sent to a separate enclave?

Section 4.5

   At step 4, since the Untrusted Application depends on the TA,
   installing the Untrusted Application will trigger TA installation by
   initiating communication with a TAM.  The TEEP Agent will interact
   with TAM via a TEEP Broker that faciliates communications between a
   TAM and the TEEP Agent in TEE.

The arrow in the figure points from TAM to device-with-TEE; is that the
direction we want it to point at, given that this prose describes the
operation being triggered on the device?  (I think it probably is, given the
way we discuss TAM requests and responses, but wanted to check.)

Section 5

   The TEE key pair and certificate are thus used for authenticating the
   TEE to a remote TAM, and for sending private data to the TEE.  [...]

This implies that the same key is used for both signing and encryption.
I think I remember some previous discusions about needing to allow this
because it's what's done in practice, and devices only including one key,
but I think we can still mention that joint security of encryption and
signature with a single key remains to some extent an open question in
academic cryptography.

Section 5.1

   Before a TAM can begin operation in the marketplace to support a
   device with a particular TEE, it must obtain a TAM certificate from a
   CA or the raw public key of a TAM that is listed in the Trust Anchor
   Store of the TEEP Agent.

Is this bit about a raw public key right?  Right now it reads like the TAM
obtains a TAM certificate from a RPK of a TAM listed in the trust anchor
store; shouldn't it be more like getting the RPK listed in the trust anchor
store, with no certificate?

Section 5.2

   A TEE determines whether TA binaries are allowed to execute by
   verifying whether their signature can be verified using
   certificate(s) or raw public key(s) in the TEE's Trust Anchor Store.

I wonder if we could use more parallel paragraph structures across sections
5.1-5.3 -- the other two start "a TEEP Agent's Trust Anchor Store contains"
and "the Trust Anchor Store in a TAM consists of", which are somewhat
similar, but both are quite different from what's written here.  That might
also let us harmonize how we discuss certificates vs. raw public keys.

Section 6.1

   A TAM message may indicate the target TEE where a Trusted Component
   should be installed.  A compliant TEEP protocol should include a
   target TEE identifier for a TEEP Broker when multiple TEEs are
   present.

I'm a bit confused about the phrasing "a compliant TEEP protocol should
include" -- does this mean anything other than "the TEEP protocol will"?

Section 9

There's a couple more points that I think we should cover.

The whole architecture is in some sense a "double-edged sword".  It provides
protection for users and device owners against malicious apps running on the
device, at the cost of the owner having to trust that the TAM is providing
the stated code.  The owner doesn't necessarily have good mechanisms for
getting visibility into what code is actually running in the TEE without
being involved in the TAM operation, and in some cases the user will have no
rights at all.   The latter runs risk of conflicting with RFC 8890, so I
really think we want some discussion of how there are ways for TEEP to
provide value to users, acknowledge that there are cases where the main
value of TEEP is to device owners potentially at risk of harm to users, and
discuss the trade-offs involved.

This architecture basically requires that the TAM know the device identity
in all transactions (device identifying information is a required claim in
§7); this has privacy implications that should be documented.  The TAM is a
trusted party in the ecosystem, but can still be a different party than
device owner or administrator, so we need to document the new privacy
exposure (and possibly the assumption that contractual controls will be
available for it).

Section 9.4

   certificate.  Such validation includes checking for certificate
   revocation.  See Section 6 of [RFC5280] for details.

Might OCSP (including stapling) or other non-CRL mechanisms be in scope?  Is
it worth mentioning RFC 6960 or 6961 as well as 5280 here?

Section 9.8

Should we mention that in this scenario we cannot even rely on the TAM to
report a public key of a TEE for use with encryption, since the TAM could
misreport the key and provide one that it controls, thereby receiving the
data that is supposed to be kept secret from it?  It is a fairly
straightforward attack, but maybe not obvious to all readers.

It also seems that if the Trusted Component Signer can interact with the
manufacturer directly, that may open up avenues for key distribution.
(Whether or not this is sufficiently interesting to be worth mentioning in
the document is something I'm not sure of.)