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

[Mingliang Pei <[e-mail]>]

Hi Russ,

Thank you very much for your detailed review, suggestions and nits. Please
see inline. Best,

Ming


On Fri, Apr 17, 2020 at 1:37 PM Russ Housley <[e-mail]> wrote:

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

MP: we will provide two examples as you suggested. We will file this in
issue tracker for a fix.


> 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.
>
>
MP: how about the following?

   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 in order for an untrusted application to
use.

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.
>
>
MP: the subscription example doesn't fully need TA removal as you said. The
first half about a "revoked TA" still calls for the help of TAM. I think we
can remove the subscription sentence. A TA could be revoked because it is
compromised, or not offered anymore. Regarding the impact on multi-user
devices, a TA is shared. A revoked TA use case should apply to all users,
which will not have the concern you mentioned. Is this good?

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.
>
>
MP: Agree on the additional line. Not sure about changing "application" to
"component". An untrusted application intends to mean a regular client
application. Trusted application is an independent application; we don't
require that the two are strongly tied. Multiple untrusted applications can
call the same trusted application.

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.
>
>
MP: DDoS attack utilized insecure design that was triggered to send
queries. If all apps are inside TEE, those apps won't be misused. But not
sure the entire IoT can just use TEE that can still provide a network
interface as you mentioned.

6) Section 3.4 talks about Confidential Cloud Computing.  Can something be
> said in Section 4.4.1 to make this less abstract?
>
>
MP: will work with co-authors on some text for review.

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.
>
>
MP: how about the following changes?

Certification Authority (CA): Certificate-based credentials used
      for authenticating a device, a TAM and a TA developer.

To

Certification Authority (CA): A CA issues certificates that can be used
      for authenticating a device, a TAM or a TA developer. Different CAs

      may be used for issuing certificates for a device, a TAM and a
TA developer.


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.
>
>
MP: prefer to pick "TA signer". Will add definition to Section 2.

9) Section 4.4 should require support for both confidentiality and
> integrity protection.
>
>
MP: it currently says

   "Implementations must support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it."

Agreed. We should add integration protection support too. How about
the following?

   "Implementations must support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it and support
integrity protection."


10) Should GlobalPlatform be added to Section 4.4.1?
>
>
MP: GP TEE can be referred to in the TrustZone section. How about the
following?

"A TA is loaded by a trusted OS running in the TEE such as a
GlobalPlatform compliant TEE,"


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

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.
>
>
MP: will revise this, and file it in Github issue tracker for text revision.

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?
>
>
MP: It isn't a common case to use a fixed public key as a trusted anchor
instead of a CA certificate. How about allowing a TAM to use a self-signed
certificate? It accommodates both.

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.
>
>
MP: we assume that signer and the intermediate CAs up to the trust anchor
but not include a trust anchor are sent in a signature payload. This can
establish a certificate path. Do you mean this about "directly by the trust
anchor"? We need to allow intermediate CAs. We can revise the paragraph to
elaborate on this if you agree.

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.
>
>
MP: please see above #13 comment.

16) Section 7 says that there are "different attestation algorithms".  Does
> this mean different set of claims?  Please be more clear here.
>
>
MP: it currently means algorithm agility and algorithms may be different
for different devices. Different set of claims from different algorithms
from one device is possible but not necessary, I think. A verifier is
expected to support all the supported algorithms such that it doesn't have
to require different claims to get one working.

We will clarify the text.

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,
>
>
MP: will track this as an issue to revise.

18) Section 18: Asymmetric algorithms are also used to manage the symmetric
> keys.  Symmetric algorithms are also used for data integrity.
>
>
MP: will revise it to reflect both points.

Symmetric algorithms are used for encryption
   of content whereas the asymmetric algorithms are mostly used for
   signing messages.

==>

Symmetric algorithms are used for encryption
   of content and data integrity whereas the asymmetric algorithms are
mostly used for
   signing messages and managing symmetric keys.


19) Section 9.4: Please expand this discussion to cover compromised trust
> anchors and compromised intermediate CAs.
>
>
MP: will file an issue to add this.

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.
>
>
MP: will add a sentence to indicate this possibility.

"

TEE device certificates are expected to be long lived, longer than
   the lifetime of a device."

==>

"TEE device certificates are expected to be long lived, longer than
   the lifetime of a device. They can be certificates that never expire
   as defined in the Section 4.1.2.5 of RFC 5280."


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

22) Nits:
>
>
MP: will fix these below. Thank you very much for these detailed comments,
suggestions, and 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/
>
> _______________________________________________
> TEEP mailing list
> [e-mail]
>
> https://clicktime.symantec.com/3AXrEd5omjpFtMENR4Ssz2L7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>