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

[Russ Housley <[e-mail]>]

> On Apr 23, 2020, at 5:55 PM, Mingliang Pei <[e-mail]> wrote:
> 
> Hi Russ, please see inline about the "application component". I understood that you want consistency. My argument is that I would rather choose to say "application" in both cases without the word "component" instead of calling both "application component".
> 
> The document currently says:
> 
>    -  Trusted Application (TA): An application component that runs in a
>       TEE.
> 
> and
> 
>    -  Untrusted Application: An application running in a Rich Execution
>       Environment.
> 
> ==>
> 
> The document currently says:
> 
>    -  Trusted Application (TA): An application that runs in a
>       TEE.
> 
> and
> 
>    -  Untrusted Application: An application that runs in a Rich Execution
>       Environment.
> 
> Does this work?

That works fine.  The inconsistency was the only issue.

Russ


> 
> Thanks,
> 
> Ming
> 
> On Thu, Apr 23, 2020 at 2:32 PM Russ Housley <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>> On Apr 22, 2020, at 2:11 AM, Mingliang Pei <mingliang.pei=[e-mail] <mailto:mingliang.pei=[e-mail]>> wrote:
>> 
>> Hi Russ, thank you for your replies. Please see inline. BTW, I have filed the agreed ones or ones needing revision in the github issue section. Best, Ming
>> 
>> 
>> On Tue, Apr 21, 2020 at 9:53 AM Russ Housley <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>>> On Apr 21, 2020, at 5:32 AM, Mingliang Pei <mingliang.pei=[e-mail] <mailto:mingliang.pei=[e-mail]>> wrote:
>>> 
>>> 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] <mailto:[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.
>> 
>> I think this is a big improvement.
>> 
>>> 
>>> 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?
>> 
>> I think we need to think about it from the TEE perspective.  We should say what would cause the TEE to delete a TA.
>> 
>> 
>> MP: it tries to show a use case for the need of TA deletion. From a TEE perspective, it may delete a TA because of a request from a TAM. A TEEP Agent will be carrying out the deletion. I see your point about "privilege" that a developer was assumed to have. How about we revise the use case as the following?
>> 
>> -  A TA may need to be deleted from a device's TEE if the TA is compromised or
>>    the right of use of the TA is revoked from a particular user (or device). There could
>>    be cases where additional TAs should be installed that some prior TAs should be
>>   deleted to free up spaces.
> 
> I think this is an improvement.
> 
> 
>> 
>>> 
>>> 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.
>> 
>> A TA is an "application component", so the Untrusted Application is also an "application component", right?  If not pick another term for both definitions.
>> 
>> 
>> MP: I filed this as an issue to welcome more comments. If we call "Untrusted Application" as "application component", it looks to me that the word "application" isn't a good fit here.
> 
> I think you are missing my point.
> 
> The document currently says:
> 
>    -  Trusted Application (TA): An application component that runs in a
>       TEE.
> 
> and
> 
>    -  Untrusted Application: An application running in a Rich Execution
>       Environment.
> 
> Why is one a component and the other not?
> 
>> 
>>> 
>>> 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.
>> 
>> I'm not sure what you are proposing to say in the document about DDoS.
>> 
>> 
>> MP: I would suggest that we say
>> 
>> "This doesn't prevent the devices being used to mount DDoS attacks where network interfaces are mostly hosted in the untrusted REE."
>> 
>> Does it work? Thanks.
> 
> Thanks.  That resolves my point.
> 
>> 
>>> 
>>> 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.
>> 
>> That seems fine.
>> 
>> 
>> Thanks.
>> 
>>> 
>>> 
>>> 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.
>> 
>> Thank you.
>> 
>>> 
>>> 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."
>> 
>> I'm glad you added integrity protection, not "integration protection" as you said above!
>> 
>> 
>> MP: good catch :)
>>> 
>>> 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,"
>> 
>> This section has a paragraph about ARM and Intel TEEs.  Elsewhere the document talks about GlobalPlatform.  I think it should get a paragraph too so that the reader can compare and contrast the three TEEs.
>> 
>> 
>> MP: I will file an issue to fix this per your recommendation.
>> 
>>> 
>>> 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.
>> 
>> That does not align with the discussion of what a trust anchor is in RFC 5280.  I think the raw key needs to be allowed, even it if is not the most popular choice in current implementations.  For example, TLS did not originally allow raw public keys, but it was added later.  Here, all of the foundational specifications already allow it, so I do not think it is wise to prohibit raw public keys.
>> 
>> 
>> MP: appreciate the additional comments. Will revise to allow the use of a raw public key.
> 
> Thanks.
> 
>> 
>>> 
>>> 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...
>> 
>> No.  Please look at RFC 5934.  Signatures are verified by the trust anchor itself or by the public key in a certificate that validates to the trust anchor.
>> 
>> 
>> MP: so the trust anchor contains those additional information per my quick reading, right? Will make the revision per your confirmation.
> 
> I think this is resolved by your response to my comment 13.
> 
>> 
>>> 
>>> 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.
>> 
>> Thanks.  I think you can drop "mostly".
>> 
>> 
>> MP: thank you. I filed an issue to fix, and dropped "mostly".
> 
> Thanks.
> 
>>> 
>>> 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.
> 
> Russ
>