Re: [Teep] The TEEP WG has placed draft-yang-teep-usecase-for-cc-in-network in state "Call For Adoption By WG Issued"

[[e-mail]]

Hi Nicolae,

Thanks for your review. I think your suggestions are very useful to 
improve the quality of this draft, and I will try to resolve these 
issues in next version.

Just for information, the use cases in section 4.1-4.5 could be used in 
examples like Federal Learning, in which the TA is the FL algorithm, and 
the PD is the data set or training result. Sometimes the FL algorithm 
and the data set are bundled together by data owner and sent to remote 
confidential computing resource for computing. Sometimes the FL 
algorithm needs to aggreaget different data owners' training result  in 
remote confidential computing resource to create the final training model.

BR
Penglin


On 8/19/2022 3:45 AM, Nicolae Paladi wrote:
>
> Hi, my brief initial review of the draft:
>
> I think this is a useful draft and it’s a good idea to provide a 
> guidance for MEC/CAN usage of confidential computing.
>
>
> Abstract:
>
>   * The abstract needs to be made clearer. Some things that are
>     missing in the abstract: (1) what problem or need is being
>     addressed; (2) on which components in the network the TEEs are
>     assumed to be deployed;
>
>
> Introduction:
>
>   * “In the scenario of confidential computing in network, network
>     users will attest the TEE in confidential computing and provision
>     private data and applications to that TEE by network. This network
>     could be a MEC[MEC], CAN or other network that provide computing
>     resource to users.” - the introduction can improved by describing
>     early on what the users represent in this scenario, and where the
>     TEEs are located in the network fabric. Similar to the abstract -
>     what is the motivation for doing this? Simply having it _possible_
>     is not enough of a reason.
>
>
> Notional Architecture:
>
>   * The Data Owner is mentioned without introduction or explanation.
>     It’s important to clarify who the data owner is? Same as the user
>     deploying data? Perhaps there are other roles, such as the data
>     source (such as the connected vehicle), the application source (a
>     third party application provider?), data owner (the owner of the
>     vehicle or the operator of the vehicle at a specific point in time?)
>
>
>
> Use cases:
>
>   * Sections 4.1-4.5 enumerate various combinations of delivering the
>     Personalization Data (PD), Trusted Application (TA) and Untrusted
>     applications (UA). Some context and examples for each of them
>     would both help readability and provide clearer motivations for
>     each of the enumerated use cases.
>
>
> Best regards,
> Nicolae
>
>
>
>> On 13 Aug 2022, at 06:36, [e-mail] wrote:
>>
>> Hi，
>>
>> In my understanding, some deploy steps are better to be remained in 
>> this draft, and some could be defined in a loose sequence.
>>
>> First, we should make sure that all the PD is unpackaged or processed 
>> inside TA. For example in section 4.1 process column, since the 
>> package contains (UA, TA and PD), the package should be unpackaged 
>> inside TEE, and then let the TEE export the UA to REE.
>>
>> Seond, we also need to consider if the TA has the ability of network 
>> communication. In some scenarios like SGX, if there is no middleware 
>> like libos or web assembly, the trusted process may have no network 
>> ability. And the TEEP broker or the UA will have to act as the role 
>> of network communication. This also means UA have to deployed before 
>> TA and PD. In Dave's feedback of 9th July, the sequence problem is 
>> also been mentioned.
>>
>> /"//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."/
>>
>> I will try to resolve this problem in next version.
>>
>> BR
>> Penglin
>>
>>
>> On 8/11/2022 9:13 AM, Meiling Chen wrote:
>>>  Hi Daniel,
>>> Thanks for your support.
>>>  Agree with you, deployment options no need every one in detail.
>>>
>>> Best,
>>> Meiling
>>>
>>>     *From:* Daniel Migault <mailto:[e-mail]>
>>>     *Date:* 2022-08-10 20:34
>>>     *To:* Meiling Chen <mailto:[e-mail]>
>>>     *CC:* IETF Secretariat
>>>     <mailto:[e-mail]>;[e-mail];[e-mail];[e-mail]
>>>     *Subject:* Re: [Teep] The TEEP WG has placed
>>>     draft-yang-teep-usecase-for-cc-in-network in state "Call For
>>>     Adoption By WG Issued"
>>>     As mentioned during the IETF114, I support the adoption of the
>>>     document and I am interested in reviewing the document.
>>>
>>>     Yours,
>>>     Daniel
>>>
>>>     On Sun, Aug 7, 2022 at 9:25 PM Meiling Chen
>>>     <[e-mail]> wrote:
>>>
>>>         Hi folks,
>>>         As one of the authors, I support the WG adoption. And I also
>>>         notice that this draft need more reviewers, if anyone have
>>>         interest, feel free to comments.
>>>
>>>         Best,
>>>         Meiling
>>>
>>>             *From:* IETF Secretariat
>>>             <mailto:[e-mail]>
>>>             *Date:* 2022-08-03 20:06
>>>             *To:*
>>>             [e-mail];[e-mail];[e-mail]
>>>             *Subject:* The TEEP WG has placed
>>>             draft-yang-teep-usecase-for-cc-in-network in state "Call
>>>             For Adoption By WG Issued"
>>>             The TEEP WG has placed
>>>             draft-yang-teep-usecase-for-cc-in-network in state
>>>             Call For Adoption By WG Issued (entered by Tirumaleswar
>>>             Reddy.K)
>>>             The document is available at
>>>             https://datatracker.ietf.org/doc/draft-yang-teep-usecase-for-cc-in-network/
>>>
>>>         _______________________________________________
>>>         TEEP mailing list
>>>         [e-mail]
>>>         https://www.ietf.org/mailman/listinfo/teep
>>>
>>>
>>>
>>>     --
>>>     Daniel Migault
>>>     Ericsson
>>>
>> _______________________________________________
>> TEEP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teep
>