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

[Dave Thaler <[e-mail]>]

Ok, I've now addressed the comments on this document and will submit an update soon.  Responses with [DT] below.



-----Original Message-----
From: Benjamin Kaduk <[e-mail]>
Sent: Friday, January 7, 2022 12:02 PM
To: [e-mail]
Cc: [e-mail]
Subject: AD review of draft-ietf-teep-architecture-15



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).



[DT] Updated text.  They're separate mostly to make explanations easier.  They're abstract APIs so an implementation might combine them.  But clarified text to say ProcessConnect is a request to create a new session, whereas ProcessTeepMessage is to deliver a message within an existing session.



I put some editorial nits in

https://github.com/ietf-teep/architecture/pull/231



[DT] Merged, thanks!



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.



[DT] Add a paragraph to the intro to explain this, but the topic is really about TEEs in general not the TEEP architecture specifically.  (Also text added in the security considerations to address your related comment at the end of this email.)  New paragraph in intro is:



  *   TEEs are typically used in cases where a software or data asset needs to be
  *   protected from unauthorized entities that may include the owner (or pwner)
  *   or possesser of a device.  This situation arises for example in gaming
  *   consoles where anti-cheat protection is a concern, devices such as ATMs or
  *   IoT devices placed in locations where attackers might have physical
  *   access, cell phones or other devices used for mobile payments, and hosted
  *   cloud environments.  Such environments can be thought of as hybrid
  *   devices where one user or administrator controls the REE where a different
  *   (remote) user or administrator controls a TEE in the same physical device.
  *   It may also be the case in some constrained devices that there is no REE
  *   (only a TEE) and there may be no local "user" per se, only a remote TEE
  *   administrator. For further discussion of such confidential computing use
  *   cases and threat model, see {{CC-Overview}} and {{CC-Technical-Analysis}}.





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.



[DT] Updated as suggested.



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



[DT] Agree.  Deleted "along with..." to end of sentence.



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?



[DT] Absolutely an important use case.  Added enterprises to the last sentence.



      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.



[DT] Updated for consistency.



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.



[DT] Updated to use "interact"



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.



[DT] Updated to list all five.   Also updated text about SGX and TrustZone that refers to the three cases to refer to five.



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?



[DT] Correct.  Updated text to clarify.



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.)



[DT] Yes, updated text.



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.



[DT] Added text as suggested.



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?



[DT] Yes, bad grammar.  Reworded to clarify.



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.



[DT] Updated as suggested.



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"?



[DT] You are correct.  Updated as suggested.



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).



[DT] The paragraph I added to the intro sets the context for this info, and then I added the following section below Security Considerations:



  *   ## REE Privacy
  *   The TEEP architecture is applicable to cases where devices have a TEE that
  *   protects data and code from the REE administrator.  In such cases, the TAM
  *   administrator, not the REE administrator, controls the TEE in the devices.  As
  *   some examples:
  *
  *   * a cloud hoster may be the REE administrator where a customer
  *      administrator controls the TEE hosted in the cloud.
  *   * a device manufacturer might control the TEE in a device purchased by a
  *      customer
  *
  *   The privacy risk is that data in the REE might be susceptible to disclosure to
  *   the TEE administrator. This risk is not introduced by the TEEP architecture,
  *   but is inherent in most uses of TEEs. This risk can be mitigated by making
  *   sure the REE administrator is aware of and explicitly chooses to have a TEE
  *   that is managed by another party.  In the cloud hoster example, this choice
  *   is made by explicitly offering a service to customers to provide TEEs for
  *   them to administer.  In the device manufacturer example, this choice is
  *   made by the customer choosing to buy a device made by a given
  *   manufacturer.





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?



[DT] At IETF 111, the TEEP WG got consensus to not depend on OCSP and remove such references from the protocol spec.   Meeting discussion is documented in https://datatracker.ietf.org/meeting/111/materials/minutes-111-teep-00 which says

among other things:

  *   Russ made the argument that OCSP stappling might be difficult for constrained node. He was arguing that there are more lightweight solutions.
  *   Ben: OCSP does not really make sense with COSE. You might just be using hard-coded keys and you might be updating keys with software updates. It is probably still worth to mention that there is a need for revocation.



Hence updated the quoted text to read:

  *   certificate.  See Section 6 of [RFC5280] for details.
  *   Such validation generally includes checking for certificate
  *   revocation, but certificate status check protocols may
  *   not scale down to constrained devices that use TEEP.





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.



[DT] Updated as suggested.



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.)



[DT] After the other updates, I didn't think it was sufficiently interesting, so no change for this.



Until the updated I-D is posted, deltas can be seen at

https://github.com/ietf-teep/architecture/pull/232/files

https://github.com/ietf-teep/architecture/pull/233/files



Dave