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

[Hannes Tschofenig <[e-mail]>]

Hi Russ,

Thanks for the detailed review. I addressed almost all of it but see my response below. Ming/DaveW/DaveT - there are also some items for you...

-----Original Message-----
From: TEEP <[e-mail]> On Behalf Of Russ Housley
Sent: Friday, April 17, 2020 10:34 PM
To: teep <[e-mail]>
Subject: [Teep] Review of draft-ietf-teep-architecture-08

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.

[Hannes] Here is the PR:
https://github.com/ietf-teep/architecture/pull/162

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.

[Hannes] Fair enough. I created a PR on this topic as well:
https://github.com/ietf-teep/architecture/pull/163

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.

[Hannes] I agree with you. This sounds a bit strange. I have changed the wording to:

  - A Device Administrator wants to remove a TA from a device's TEE if
    the TA developer is no longer maintaining that TA, when the TA has
    been revoked or is not used for other reasons anymore (e.g. due to an
    expired subscription).

The PR is:
https://github.com/ietf-teep/architecture/pull/163

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.

[Hannes] Sounds useful to me. PR is here:
https://github.com/ietf-teep/architecture/pull/164

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.

[Hannes] The DDoS attacks you are referring to were caused by default passwords on those devices. A TEE cannot help with that directly. You can, of course, put per-device credentials and isolate them better using the TEE. The problem with the DDoS attacks of these IP-based cameras wasn't the lack of isolation of software but the fact that all devices used the same credentials and that those credentials were public. I am not sure what I could write to talk about these use cases without making too many assumptions.

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

[Hannes] This is a question for DaveT. Maybe there is some text that could be copied from the CCC.

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.

[Hannes] Stupid mistake. Here is the PR:
https://github.com/ietf-teep/architecture/pull/165

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.

[Hannes] Good catch. I have expanded the text for the TA developer in the intro section and have also removed the terms "TA software author" and "TA signer" with the term "TA developer".

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

[Hannes] Of course. I correct it. Here is the Pr:
https://github.com/ietf-teep/architecture/pull/165

10) Should GlobalPlatform be added to Section 4.4.1?

[Hannes] GlobalPlatform defined APIs that simplify the experience of developers when need to pass information between the Untrusted App and the TA (and also for the TA to access secure world OS features). I could add text but I am wondering whether this would go a bit too far.

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

[Hannes] I hope I removed all occurrences.

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.

[Hannes] I changed the text in this PR but I wanted to note that we don't want to go into the details on how the encryption works because the details, as you point out, vary a bit from mechanism to mechanism.

PR:
https://github.com/ietf-teep/architecture/pull/166

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?

[Hannes] I enhanced that sentence.

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.

[Hannes] I have updated the text but have a look whether I captured everything. Here is the PR:
https://github.com/ietf-teep/architecture/pull/166

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.

[Hannes] I removed it because I don't think that self-signed certificates really make sense given what we described elsewhere.

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

[Hannes] The idea was to be flexible with regards to attestation schemes, like ECDSA-based attestation, Direct Anonymous Attestation (DAA), Enhanced Privacy ID (EPID), a Privacy CA, etc. With our decision to support EAT tokens I believe we pushed the responsibility over to RATS.

I still added a few examples:
https://github.com/ietf-teep/architecture/pull/167

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,

[Hannes] @DaveW: Can you take care of this? I believe you wrote that section.

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

[Hannes] I added a remark on this topic in this PR:
https://github.com/ietf-teep/architecture/pull/168

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

[Hannes] @Ming: Can I push this to you? I believe you wrote that text.

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.

[Hannes] Good idea. Here is the PR:
https://github.com/ietf-teep/architecture/pull/168

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

[Hannes] DaveT/DaveW: What reference should I use for SGX?

22) Nits:

I covered the nits below in the following PR:
https://github.com/ietf-teep/architecture/pull/169

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.