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

From: Russ Housley <[email-masked]>
Date: Fri, 17 Apr 2020 16:33:49 -0400

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/

---

From: Mingliang Pei <[email-masked]>
Date: Tue, 21 Apr 2020 02:32:43 -0700

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 <[email-masked]> wrote:

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

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

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

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 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
> [email-masked]
>
> https://clicktime.symantec.com/3AXrEd5omjpFtMENR4Ssz2L7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 21 Apr 2020 14:45:47 +0000

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 <[email-masked]> On Behalf Of Russ Housley
Sent: Friday, April 17, 2020 10:34 PM
To: teep <[email-masked]>
Subject: [Teep] Review of draft-ietf-teep-architecture-08

1) Section 1 says:

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

2) Section 1 says:

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

3) Section 1 offers:

[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:

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

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

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

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

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

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

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

[Hannes] I hope I removed all occurrences.

[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

[Hannes] I enhanced that sentence.

[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

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

[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

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

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

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

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

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 21 Apr 2020 12:48:58 -0400

> On Apr 21, 2020, at 5:32 AM, Mingliang Pei <mingliang.pei=[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> MP: we will provide two examples as you suggested. We will file this in issue tracker for a fix.
> 
> 
> 2) Section 1 says:
> 
>    of various devices is needed in order for an untrusted application to use.

I think this is a big improvement.

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

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

That seems fine.

> MP: prefer to pick "TA signer". Will add definition to Section 2.

Thank you.

> Agreed. We should add integration protection support too. How about the following?
> 
>    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: 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.

> 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: 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: 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.
> 
>    of content and data integrity whereas the asymmetric algorithms are mostly used for

Thanks.  I think you can drop "mostly".

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

Russ

---

From: Mingliang Pei <[email-masked]>
Date: Tue, 21 Apr 2020 23:11:48 -0700

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 <[email-masked]> wrote:

>
>
> On Apr 21, 2020, at 5:32 AM, Mingliang Pei <
> mingliang.pei=[email-masked]> wrote:
>
> Hi Russ,
>
>> On the last TEEP call, I agreed to review the TEEP Architecture
>> document.  Here are my comments and questions.
>>
>> 1) Section 1 says:
>>
> 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?
>
>
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.

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

>       may be used for issuing certificates for a device, a TAM and a TA developer.
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: good catch :)

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

>> however, Section 1 said that a trust anchor could be a raw public key..
>> Can the TAM use the raw trust anchor key directly?
>>
>>
> 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.

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

> 16) Section 7 says that there are "different attestation algorithms".
>> Does this mean different set of claims?  Please be more clear here.
>>
>>
> 18) Section 18: Asymmetric algorithms are also used to manage the
>> symmetric keys.  Symmetric algorithms are also used for data integrity.
>>
>>
MP: thank you. I filed an issue to fix, and dropped "mostly".

---

From: Mingliang Pei <[email-masked]>
Date: Tue, 21 Apr 2020 23:36:55 -0700

Hi Hannes,

Thanks for actually making fixes via PRs. My comments included some
revisions, and I filed them as issues to track and fix. I will link the
issue list with your PRs.

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

Yes. I will create a PR for it.

Ming

On Tue, Apr 21, 2020 at 7:48 AM Hannes Tschofenig <[email-masked]>
wrote:

> 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...
>
> https://clicktime.symantec.com/3U9tRcBXS9neAQm3h31kB7c7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F162
>
> 2) Section 1 says:
>
> https://clicktime.symantec.com/3LecjoZBjbLnxFYgDEAkn5G7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F163
>
> 3) Section 1 offers:
>
> https://clicktime.symantec.com/3LecjoZBjbLnxFYgDEAkn5G7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F163
>
> 4) Section 2 says:
>
> https://clicktime.symantec.com/3BGyEGWFVwCayAKAwStemYY7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F164
>
> [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.
>
> https://clicktime.symantec.com/3QdbngvsC8Pbwe91EKXejbh7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F165
>
> [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".
>
> https://clicktime.symantec.com/3QdbngvsC8Pbwe91EKXejbh7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F165
>
> [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.
>
> [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://clicktime.symantec.com/3PnJTUn12pPi5vDzwLbKrXT7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F166
>
> https://clicktime.symantec.com/3PnJTUn12pPi5vDzwLbKrXT7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F166
>
> [Hannes] I removed it because I don't think that self-signed certificates
> really make sense given what we described elsewhere.
>
> [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.
>
> https://clicktime.symantec.com/3NyQiEpcnNaSDdKAKkVpxHz7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F167
>
> https://clicktime.symantec.com/3SmGXqTfEyAyyAhffX1HMyF7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F168
>
> https://clicktime.symantec.com/3SmGXqTfEyAyyAhffX1HMyF7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F168
>
> https://clicktime.symantec.com/3UPSKdb8ibLcLv5mnwFRLJV7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F169
>
> 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.
>
> https://clicktime.symantec.com/3K8CZpBGrTEYE9VTkz6AaN7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 23 Apr 2020 17:32:00 -0400

> On Apr 22, 2020, at 2:11 AM, Mingliang Pei <mingliang.pei=[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Apr 21, 2020, at 5:32 AM, Mingliang Pei <mingliang.pei=[email-masked] <mailto:mingliang.pei=[email-masked]>> wrote:
>> 
>> Hi Russ,
>> 
> 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

I think this is an improvement.

> 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

Why is one a component and the other not?

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

>> 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: appreciate the additional comments. Will revise to allow the use of a raw public key.

Thanks.

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

Thanks.

Russ

---

From: Mingliang Pei <[email-masked]>
Date: Thu, 23 Apr 2020 14:55:35 -0700

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

and

==>

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

Thanks,

Ming

On Thu, Apr 23, 2020 at 2:32 PM Russ Housley <[email-masked]> wrote:

>
>
> On Apr 22, 2020, at 2:11 AM, Mingliang Pei <
>> 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: Agree on the additional line. Not sure about changing "application"
>> to "component". An untrusted application intends to mean a regular client
>> 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
>> 6) Section 3.4 talks about Confidential Cloud Computing.  Can something
>>> be said in Section 4.4.1 to make this less abstract?
>>>
>>>
>>> however, Section 1 said that a trust anchor could be a raw public key...
>> 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.
>>
>>
>> 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

---

From: Russ Housley <[email-masked]>
Date: Thu, 23 Apr 2020 17:58:08 -0400

> On Apr 23, 2020, at 5:55 PM, Mingliang Pei <[email-masked]> 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".
> 

That works fine.  The inconsistency was the only issue.

Russ

> 
> Thanks,
> 
> Ming
> 
> On Thu, Apr 23, 2020 at 2:32 PM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Apr 22, 2020, at 2:11 AM, Mingliang Pei <mingliang.pei=[email-masked] <mailto:mingliang.pei=[email-masked]>> wrote:
>>

---

From: Mingliang Pei <[email-masked]>
Date: Thu, 23 Apr 2020 15:01:11 -0700

Thanks Russ. Will update to reflect this, Ming

On Thu, Apr 23, 2020 at 2:58 PM Russ Housley <[email-masked]> wrote:

>>> 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.
>>>>
>>>>
>>> 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.
>>>>
>>>>
>>> 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...
>>>
>>>
>> MP: so the trust anchor contains those additional information per my
>> quick reading, right? Will make the revision per your confirmation.
>>
>>
>>> 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,
>>>>
>>>>