[Teep] Review of draft-ietf-teep-architecture-08

[Russ Housley <[e-mail]>]

On the last TEEP call, I agreed to review the TEEP Architecture document.  Here are my comments and questions.

1) Section 1 says:

   Typically, application components are chosen to execute inside a TEE
   because those application components perform security sensitive
   operations or operate on sensitive data.

Recognizing that this is the introduction, I was wondering if you could provide a bit more explanation here.  Earlier in the paragraph, the document offers an example of a banking application.  There would be components of such and application that are trusted, and other components would be untrusted. This concept is described, but the coupling to make a complete application could be more explicit to prepare the reader for the detail that is coming.  Within such an application, it would be good to offer an example of a security sensitive operations and a separate example of operating on sensitive data.

2) Section 1 says:

   To simplify the life of TA developers interacting with TAs in a TEE,
   an interoperable protocol for managing TAs running in different TEEs
   of various devices is needed.

This feels incomplete to me.  Making sure that compatible trusted and untrusted components of an application are installed on the same device is vital when they are not bundled.

3) Section 1 offers:

   -  A TA developer wants to remove a confidential TA from a device's
      TEE if the TA developer is no longer offering such TAs or the TAs
      are being revoked from a particular user (or device).  For
      example, if a subscription or contract for a particular service
      has expired, or a payment by the user has not been completed or
      has been rescinded.

This implies that the TA developer has some of the privileges that I associate with the TAM.  Yes, I see the note at the end of the bullets, but I think this is an indication that the privileges are not quite right for these roles.  Also, if I was writing a TA for a subscription, I would have the TA perform some form of payment checking, and then refuse to decrypt the content if the payment checking fails.  Perhaps the REE passes a signed proof of payment.  This way, the TA developer does not need to actually have permission to remove a TA. Further, if the TA is on a multi-user device, removing the TA would adversely impact other users.

4) Section 2 says:

   -  Untrusted Application: An application running in a Rich Execution
      Environment.

For alignment with the definition of a TA and te terms used in section 1, I think this should say:

   -  Untrusted Application: An application component that runs in a
      REE.

It is also useful to indicate that the Untrusted Application may be dependent on one or more TAs.

5) Section 3.3 talks about the Internet of Things.  It does not talk about the billions of devices being used to mount DDoS attacks.  Can it cover that too?  Without putting the network interface inside the TEE, I'm skeptical there is a solution.

6) Section 3.4 talks about Confidential Cloud Computing.  Can something be said in Section 4.4.1 to make this less abstract?

7) Section 4.1 defines CA incorrectly.  A CA is not "Certificate-based credentials".  A CA issues certificates, and the certificates are then used for authentication and cryptographic key management.  This bullet should begin: "A CA is ..." to follow the pattern of the other bullets.

8) Section 4.3 introduces the term "TA software author" and "TA signer."  I hope we ca pick one.  Please add the term that is chosen to Section 2.

9) Section 4.4 should require support for both confidentiality and integrity protection.

10) Should GlobalPlatform be added to Section 4.4.1?

11) Section 4.5 uses the term "TA binary signers" and "TA signer".  Please see comment 8 above.

12) Section 5 says: "... encrypted with the TAM public key ...".  This is not correct.  The TAM public key is used to establish the key that is then used for encryption and decryption.  Further the wording is aimed at RSA, which is a key transport algorithm.  Please make the wording accommodate key transport and key agreement approaches.

13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA"; however, Section 1 said that a trust anchor could be a raw public key.  Can the TAM use the raw trust anchor key directly?

14) Section 5.2 and Section 5.3 should allow signatures to be directly by the trust anchor.  The current working requires a certification path.

15) Section 5.4 says that "self-signed certificates" are allowed.  I think this is the same as allowing signatures to be directly by the trust anchor.  Please consider this comment in conjunction with comment 13 above.

16) Section 7 says that there are "different attestation algorithms".  Does this mean different set of claims?  Please be more clear here.

17) I think the discussion about "assumptions" would be better written as things that need to be considered when assessing the degree of confidence in the claim by the TEE,

18) Section 18: Asymmetric algorithms are also used to manage the symmetric keys.  Symmetric algorithms are also used for data integrity.

19) Section 9.4: Please expand this discussion to cover compromised trust anchors and compromised intermediate CAs.

20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, which tells how to make a device certificate that never expires.

21) Please add references for SGX and TrustZone, adding the citations in the body as appropriate.

22) Nits:

Section 3.1: s/trust about the hosting device/trust in the hosting device/

Section 3.1: s/unlocking the phone/unlocking the device/

Section 4.1: s/certificate/certificate [RFC5280]/

Section 4.2: s/Rich Execution Environment/REE/ (several places)

Section 4.5: s/and TA signer verification/and TA signature verification/

Section 4.5: s/nnetwork/network/

Section 5: s/chains up to some CA/chains up to some trust anchor/

Section 5: s/Figure 4: Keys/Figure 4: Signature Keys/

Section 7: s/different standards for/require different degrees of confidence in/

Section 8, sentence 1: s/algorithm suite/cryptographic algorithm suite/

Section 9.8: s/public key of the TEE that it can use to encrypt/public key of the TEE to establish a symmetric key for encryption/