Re: [Teep] draft-yang-teep-usecase-for-cc-in-network-00

["[e-mail]" <[e-mail]>]

Hi Dave and all,

Thanks for your great suggestions. In general, I agree with you about these comments and will refine the draft in next version. Only one concern is in the 4th feedback. If the UA is a separate package, should this architecture ignore it and let REE to handle it by other mechanism? My concern is that it would be more convenient for network user if the TAM could handle both UA and TA. While indeed from the definition of TAM, UA is not in its management scope. So, maybe your suggestion is more accurate and I just mention this concern here.

BR.
Penglin



 
From: Dave Thaler
Date: 2022-07-19 05:49
To: [e-mail]; teep
CC: 粟栗; chenmeiling
Subject: [Teep] draft-yang-teep-usecase-for-cc-in-network-00
I have reviewed this document, and I think it is an interesting use case.
(I sent Penglin email containing some editorial things separately, so
will confine this message to technical comments.)  Also FYI to others in TEEP:
Penglin also presented this draft in the Confidential Computing Consortium’s
Technical Advisory Council meeting recently.
 
I understand that the use case is very similar to a cloud scenario for confidential computing, except that the TEEs are running in devices close to the edge, say operated by a network operator.   Like the cloud case, the intent is to allow
customers to run confidential workloads without having to trust the operator
with the data.  I think that’s a useful addition to the WG’s list of scenarios we talk about.
 
I also found the discussion of cases of TA+PD with no UA a useful addition.
Classic TEEP scenarios talked about a UA when the TEE is in a user-device such as a phone or laptop or PC or IoT gadget.   This draft adds the notion (which also occurs in the cloud) that there may be no need for a UA per se, as long as the TA hosting environment itself is capable of networking.   This wasn’t very typical back when TEEP was chartered but I think is becoming more and more viable now.
 
Some technical feedback on the content of this draft are:
 
It talks about the TAM (which is the relying party in attestation) forwarding the attestation result to the user (data provider).  I agree the data provider needs to get it if it wants to communicate with the TEEP agent to provide a decryption key or whatever else.  However, I don’t think it has to get it from the TAM, but could get it directly from the TEEP Agent  For example, if the data provider has its own TAM just for handing out the key, then the TEEP Agent would reach out to the data provider and provide the attestation payload directly.  So I think the language should be loosened here rather than overly constrained.
 
Section 4.1 step 5 talks about the data provider (“network user”) establishing a channel with the TEEP Agent “via TAM” but I don’t think the TAM needs to be an intermediary in such a channel.  Maybe this comment is the same as my point 1 above.  The notion of hosting a separate TAM for PD is discussed in the architecture draft already, and the description key is just an example of such PD.
 
On 4.2 talks about SGX in an example saying “UA must be deployed first, then let the UA to deploy TA in SGX”.  But in SGX where enclave code is just stored in the regular filesystem, “deploy” (as in copy to local storage) and “load” are different steps that happen at different times.   So you can deploy an enclave to the local disk, and only “load” it into the TEE when needed which I wouldn’t refer to as “deploy”.  I think just changing “deploy” to “load” is probably what you mean here.  But this gets to why section 1 of draft-ietf-teep-architecture says:
 
> For TEEs that simply verify and load signed TA's from an untrusted
> filesystem, classic application distribution protocols can be used
> without modification.  The problems in the bullets above, on the
> other hand, require a new protocol, i.e., the TEEP protocol. 
 
That is, if you’re just using classic SGX enclaves (as opposed to a libOS style solution with SGX), you don’t need the TEEP protocol, it’s more overkill.
 
Section 4.3 talks about transferring the UA to the TAM, in a case where the UA isn’t bundled with the TA or PD.   I would assert that the TAM need not (and arguably should not) be in the path for UA-only distribution.  The TAM can just be used to distribute the UA URI (as part of the TA manifest for example), and let the REE installer on the agent device install it directly.
 
Hope this feedback is helpful,
Dave
 
From: TEEP <[e-mail]> On Behalf Of Hannes Tschofenig
Sent: Monday, March 14, 2022 4:30 AM
To: [e-mail]; [e-mail]; teep <[e-mail]>
Cc: 粟栗 <[e-mail]>; chenmeiling <[e-mail]>
Subject: Re: [Teep] apply for presentation
 
Hi Penglin, 
 
Thanks for submitting your daft <draft-yang-teep-ccican-00> to the working group. 
 
As you know, the TEEP protocol is used to provision trusted applications (along with personalization data) to TEEs. 
As the technology for TEEs advances (for example into the area of confidential computing), you obtain additional benefits. 
 
I agree with you that TEEP can be used also for these new types of TEEs that offer confidential computing. 
 
Ciao
Hannes
 
From: TEEP <[e-mail]> On Behalf Of [e-mail]
Sent: Sunday, March 13, 2022 3:51 AM
To: [e-mail]; teep <[e-mail]>
Cc: 粟栗 <[e-mail]>; chenmeiling <[e-mail]>
Subject: [Teep] apply for presentation
 
Dear chairs and all,
 
This is the author of draft "architecture of confidential computing in computing aware network". This draft describes the usage of TEEP and RATs in the concept of Computing-aware Networking (CAN) to generate a confidential computing environment for network users. 
CAN, which is computing and network resource joint optimization based on the awareness, control and management over network and computing resources, to determine the appropriate service node，dispatch the service request and provide a better user experience. And based on the definition of confidential computing consortium, confidential computing is the protection of data in use by performing computation in a hardware-based Trusted Execution Environment. When Confidential computing joins with CAN, network user's application and data will be protected with confidentiality and integrity. 
 
Both CAN and confidential computing are new technology with big potential. It is very interesting and meaningful to combines these two techs together to provide a more convenient and secure network and computing infrastructure. This draft is the premier edition of this idea, if possible I would like to apply for a time slot like 10 minutes to make a presentation and discussion about this draft. 
 
BR.
Penglin
 
 
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.