Re: [Teep] TEEP Architecture Last Call Review
Mingliang Pei <mingliang.pei@broadcom.com> Wed, 19 October 2022 09:32 UTC
Return-Path: <mingliang.pei@broadcom.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CA7C14CE2D for <teep@ietfa.amsl.com>; Wed, 19 Oct 2022 02:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.665
X-Spam-Level:
X-Spam-Status: No, score=-7.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsIYZbZZ5myn for <teep@ietfa.amsl.com>; Wed, 19 Oct 2022 02:32:53 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2606FC14CE22 for <teep@ietf.org>; Wed, 19 Oct 2022 02:32:52 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id l22so24349007edj.5 for <teep@ietf.org>; Wed, 19 Oct 2022 02:32:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=nmvffX4YUJl2oRiAKGi/Zjsf2voGTLqccgv0lzk6TRo=; b=aocmFV28Lwr5qjHLX4a443ywLSLKCD7P+OMxYPsu4LG1CZAbBXsSF76QF1PeSUbuc8 FBhaIy3/VmsE9rro4dqLz0/UQ3k+PUouHlqNw9qEqbP5OeNPUVPIaEpG+Bd0PIqby3z5 aoHznQX7MY4IIggi3QO4siRR4SZppn228GVN4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=nmvffX4YUJl2oRiAKGi/Zjsf2voGTLqccgv0lzk6TRo=; b=O/LfUlrrPQyTI4Sh0qDgibs7ZMYeGfjfp5SFjXZIMbsRYyO1PGk+4BY1yFRbVDoh31 eaxMyO2AK4scVyUsJMx/TFzvNc9hVLrjdMoBAyITTquS+URLB+7tCEBzLwFqHDre2kEm bxkgXq/shov/DgDzP+QmkRZYrOcEgQCLHLqgItMO4ryI8cRU2+viXbAuWxn7PdNoibHi ihbFZ52TufpzzHVvoeC8N/Ha4EXfKgZL342mzQvlLR3Va/e9JIXUw96V+2CiNL5wh+FN mAlGiogIBrh9eGMbBULMwmAJcSJpVOfuUdgZZZRt6+cuPNhaKtNClNxEwfpJFy2IgS/b ck1Q==
X-Gm-Message-State: ACrzQf2WoH642lGIQAfigaPuM4qS/QvDEKALlr8POCOInYS3JXIKEaSp 3u15xHS51GFPTvzkcZsZ04in5tLeWPKDf/unVQ4eSjmCkVUjPVJ1L5ovQhWPFKowUC+9az3He2d 4OLFZvKpuPKSjZ5MHp7c=
X-Google-Smtp-Source: AMsMyM6/gb2uB4FeKMneDunUwl1kXdBnitK/Mb0XQO6SBXbHWFLqVN9JtWyAMH57hD4m+EBFceYxt9NEPyTbhkLaaeA=
X-Received: by 2002:a05:6402:3890:b0:45c:2b5:b622 with SMTP id fd16-20020a056402389000b0045c02b5b622mr6619346edb.69.1666171970622; Wed, 19 Oct 2022 02:32:50 -0700 (PDT)
MIME-Version: 1.0
From: Mingliang Pei <mingliang.pei@broadcom.com>
Date: Wed, 19 Oct 2022 02:32:39 -0700
Message-ID: <CABDGos5jh-DUr4Tmv=yp7S+5tVMAUuvrrxq85TZBbt+REf=c1Q@mail.gmail.com>
To: bemasc@google.com
Cc: teep <teep@ietf.org>, teep-chairs@ietf.org, Paul Wouters <paul.wouters@aiven.io>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000007b6b1905eb5fe453"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/ieJ7noj2_3TyQZWBsnhM_r-4cCI>
Subject: Re: [Teep] TEEP Architecture Last Call Review
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2022 09:32:57 -0000
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.
- Re: [Teep] TEEP Architecture Last Call Review Mingliang Pei
- Re: [Teep] TEEP Architecture Last Call Review Mingliang Pei
- Re: [Teep] TEEP Architecture Last Call Review Ines Robles
- Re: [Teep] TEEP Architecture Last Call Review Mingliang Pei
- Re: [Teep] TEEP Architecture Last Call Review Ben Schwartz
- Re: [Teep] TEEP Architecture Last Call Review Mingliang Pei
- Re: [Teep] TEEP Architecture Last Call Review Brendan Moran
- Re: [Teep] TEEP Architecture Last Call Review Ben Schwartz
- Re: [Teep] TEEP Architecture Last Call Review Mingliang Pei
- Re: [Teep] TEEP Architecture Last Call Review Ben Schwartz
- Re: [Teep] TEEP Architecture Last Call Review Mingliang Pei