Re: [Teep] TEEP Architecture Last Call Review

[Ben Schwartz <[e-mail]>]

Thanks for considering this input!  I haven't read the draft recently, so I
don't have more to add on how to address these issues.

On Wed, Oct 19, 2022 at 5:32 AM Mingliang Pei <[e-mail]>
wrote:

> Hi Ben,
>
> Thank you very much for your review and suggestions as tracked here
> <https://datatracker.ietf.org/doc/review-ietf-teep-architecture-16-secdir-lc-schwartz-2022-04-04/>.
> Somehow we didn't notice it until recently and we have tracked it as Issue
> #251 <https://github.com/ietf-teep/architecture/issues/251> in Github
> TEEP project.
>
> We have added inputs for each of your suggestions or questions, and
> adopted suggestions into the doc revision. There are a few comments that we
> would like to follow up with you. Please see full replies below. I am
> copying the comments from #251 issue here. It will be great if you can
> reply as comments in the github issue above. It is fine too we exchange
> here, and we will incorporate our discussions to the issue tracker for
> further revision references.
>
> -----
>
> > Section 1:
> The use of the term "applications" carries an implication of a client-side
> device with installable software, but TEEP seems to extend also to server
> software sharing a kernel, hypervisors sharing a mainboard, etc. A term
> like
> "software" would be more neutral.
>
> This would be a major change in the doc. We authors will review for a
> consensus.
>
> > "An application component ... is referred to as a Trusted Application":
> This is
> confusing. A component, explicitly not an entire "application", is
> referred to
> as an "application". "Trusted Component" would be more consistent.
>
> The doc has defined a TA to mean possibly an "application component" in
> the Terminology Section as follows:
>
> "- Trusted Application (TA): An application (or, in some implementations,
> an application component) that runs in a TEE"
>
> The change would be a significant change across the doc, including APIs to
> be consistent when "Trusted Application" is replaced with "Trusted
> Component" everywhere. Can we continue to use the above definition to cover
> both cases?
>
> > Also, "trusted" seems to be the wrong adjective here, as it is the
> environment, and
> not the software, that carries an elevated level of trust. "Isolated"
> might be
> a better descriptor.
>
> > If this is common terminology for the field, a citation would be good.
>
> Not sure that a name "Isolated Component" is more natural than "Trusted
> Component".
>
> > I would appreciate some discussion of whether the Device Owner needs to
> trust
> the Trusted Application, i.e. interaction between enclaves and sandboxes.
>
> Sounds good. A Device Owner may not always have control over TAs that go
> to its device regardless of the owner's trust. A Device Administrator may
> often decide when the Administrator is different from the owner. Secondly,
> the trust to a TA is delegated to the TAMs that may manage the TAs for
> installation to devices.
>
> @dthaler <https://github.com/dthaler> @hannestschofenig
> <https://github.com/hannestschofenig> how do you think?
>
> > "verify the ... rights of TA developers": "rights" is a loaded term.
> Rather
> than get into constitutional law, consider "permissions".
>
> Agreed. Fixed.
>
> > "so that the Untrusted Application can complete" -> "so that
> installation of
> the Untrusted Application can complete".
>
> Agreed. Fixed.
>
> > "is considered confidential" -- By whom? From whom? Consider "A
> developer who
> wants to provide a TA without revealing its code to the device owner..."
>
> Agreed. Just note that the developer may not even want to share the code
> with a TAM that distributes the binary. So it isn't only protecting from a
> device owner. Proposed fix:
>
> A Trusted Component might also be encrypted,
> if the code is considered confidential, for example, when a developer wants to
> provide a TA without revealing its code to others.
>
> > "A TEE ... wants to determine" ... excessive personification. I suggest
> "needs".
>
> Agreed. Fixed.
>
> > Section 2:
> "it is more common for the enterprise to own the device, and any device
> user
> has no or limited administration rights": Grammar issue. Perhaps "and for
> any
> device user to have ...".
>
> Agreed. Adopted in fix.
>
> > Section 3.1
> "trusted user interface" ... can you cite an example of a mobile device
> with a
> trusted peripheral that is not accessible to the REE OS? This seems
> theoretical.
>
> Need help from co-authors here too.
>
> > Section 3.3
> Similarly, are there any examples of IoT devices that prevent the REE OS
> from
> operating certain actuators?
>
> We will follow up on this.
>
> > Section 4.1
> the TAM cannot directly contact a TEEP
> Agent, but must wait for the TEEP Broker to contact the TAM
> requesting a particular service. This architecture is intentional
> in order to accommodate network and application firewalls
>
> > This is true in many use cases, but for Confidential Cloud the reverse
> logic
> applies. In fact, the TAM could be operating on-site inside an enterprise,
> requiring a firewall exception to be reachable from the TEEP Broker. This
> architecture is also unnatural: it converts an event-driven "update
> command"
> into a polling loop that adds delay and wastes resources. Why is this part
> of
> the TEEP architecture? Surely it could be handled by a reversal-of-control
> pattern one layer below TEEP (e.g. Server-sent events)?
>
> > I think the real motivation here is (1) installation is presumed to be
> triggered locally, by the Untrusted Application, so the TAM must be
> reachable
> as a "server", and the other side naturally should keep the client role;
> (2)
> the TAM is intended to have O(1) state while serving N devices.
>
> Right, that was the main use case and motivation for the architecture.
>
> > For a TAM to be successful,
> it must have its public key or certificate installed in a device's
> Trust Anchor Store.
> This needs discussion of threat model. What damage can a hostile TAM do?
> What
> does the device administrator need to know for adding a trust anchor to be
> safe?
>
> This has been addressed in "Section 9.5 Compromised TAM" in a version
> after the review was posted.
>
> > Section 4.4
> Implementations must support encryption of
> such Personalization Data to preserve the confidentiality of
> potentially sensitive data contained within it,
>
> > Implementations of what?
>
> Changed to "Implementations of TEEP protocol"
>
> > and must support
> integrity protection of the Personalization Data.
>
> Lower-case "must" without explanation. Why, and is this a normative
> requirement?
>
> We chose to not use MUST in the doc to differentiate "normative" from
> "informal" requirements. To discuss this. @dthaler
> <https://github.com/dthaler> @hannestschofenig
> <https://github.com/hannestschofenig>
>
> > Section 4.4.2
> "e.g., OP-TEE" -> What is this?
>
> Changed to "e.g., OP-TEE, an open source TEE"
>
> > Section 5.4
>
> > When a PKI is used, many intermediate CA certificates can chain to a
> root certificate, each of which can issue many certificates.
>
> > Intermediate CAs have a troubled history (e.g. [1]), and techniques that
> make
> them safer (e.g. x.509 name constraints) can't be deployed as a retrofit.
> Does
> TEEP need some rules about supported x.509 extensions?
>
> We leave this to the device provider for the constraints on X509
> extensions it supports and uses in Trust Anchor validation. They may select
> to trust only a selected intermediate CA instead of the root as the Trust
> Anchor.
>
> *Is this fine?*
>
> > Section 6.2.1
>
> > If an Untrusted Application is summarily deleted, how do you avoid
> leaking the
> TA?
>
> Similar to the removal of a buggy or malicious TA, this is up to a device
> to have some scheme to contact TAM or be contacted to initiative a removal
> of TAs that are not needed anymore.
>
> > Section 7
>
> > TEEP is format-agnostic for attestations, but what about
> message-sequence-agnostic? Can it tunnel arbitrary challenge-response
> sequences?
>
> There are some limitations in TEEP about supporting arbitrary
> challenge-response sequences. It generally complies with RATS recommended
> sequence. A single pass attestation and verifier flow is assumed. A
> challenge may be supported by sending it in a request from a TAM to the
> device where the device will combine the challenge in its attestation
> evidence generation.
>
> > Section 9.3
>
> > We have
> already seen examples of attacks on the public Internet with billions
> of compromised devices being used to mount DDoS attacks.
>
> > Citation please. Also, are you sure it has reached into billions?
>
> Changed to "a large number".
>
> > Section 9:
>
> > Nothing here seems to discuss attacks on the TEE's properties, and the
> post-compromise implications of those attacks. For example, if all
> instances
> of a TA share a secret key, used for decrypting the Personalization Data,
> then
> a single successful attack on a TEE is sufficient to decrypt all
> Personalization Data (previous and future). Given the prevalence of such
> attacks (especially via hardware fault injection), it seems likely to be
> worth
> mentioning.
>
> In general, we expect that a different secret key is used for different
> devices for Personalization Data encryption. Such a secret key is delivered
> to a TA using the public key of the TEE in the device. Such a shared secret
> key for all TA instances isn't a common case.
>
> To mitigate this happening, I think we can add a statement to require that
> Personalization Data must not be encrypted with the same key for all
> devices.
>
> How do you think? I will also get other co-authors's inputs on this.
>
> Again, thank you very much for your detailed review and suggestions.
>
> Best,
>
> Ming
>
>
>
> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the use of the individual or entity to whom it is addressed and
> may contain information that is confidential, legally privileged, protected
> by privacy laws, or otherwise restricted from disclosure to anyone else. If
> you are not the intended recipient or the person responsible for delivering
> the e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.