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

[Mingliang Pei <[e-mail]>]

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 <[e-mail]>
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...
>
> -----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://clicktime.symantec.com/3U9tRcBXS9neAQm3h31kB7c7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F162
>
> 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://clicktime.symantec.com/3LecjoZBjbLnxFYgDEAkn5G7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F163
>
> 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://clicktime.symantec.com/3LecjoZBjbLnxFYgDEAkn5G7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F163
>
> 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://clicktime.symantec.com/3BGyEGWFVwCayAKAwStemYY7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F164
>
> 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://clicktime.symantec.com/3QdbngvsC8Pbwe91EKXejbh7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F165
>
> 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://clicktime.symantec.com/3QdbngvsC8Pbwe91EKXejbh7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F165
>
> 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://clicktime.symantec.com/3PnJTUn12pPi5vDzwLbKrXT7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F166
>
> 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://clicktime.symantec.com/3PnJTUn12pPi5vDzwLbKrXT7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F166
>
> 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://clicktime.symantec.com/3NyQiEpcnNaSDdKAKkVpxHz7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F167
>
> 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://clicktime.symantec.com/3SmGXqTfEyAyyAhffX1HMyF7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F168
>
> 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://clicktime.symantec.com/3SmGXqTfEyAyyAhffX1HMyF7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F168
>
> 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://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.
>
> _______________________________________________
> TEEP mailing list
> [e-mail]
>
> https://clicktime.symantec.com/3K8CZpBGrTEYE9VTkz6AaN7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>