The protocol flow is significantly missing the design rationale and description, for example, the following important symbols are not defined in the text: TIK, CAB, hs and sig. Fig. 8 and its notations are very confusing. Who owns TIK? The following questions assume it is with Attestation Service.
Does Attestation Service in Fig. 8 correspond to TEE-hosted confidential workload (e.g., Realm)?
Which entity in the CCA model does Server correspond to?
Is sig representing the signature? Clarify in text.
Is hs the handshake transcript? Clarify in text.
Are CAB, KAT and PAT as defined in I-D.bft-rats-kat? If yes, then specify in the text.
The notation sign(TIK,hs) is very confusing. Specifically, it is not clear what exactly is sent on the wire. Only hs may be sent in this case to be signed by TIK from Attestation Service.
What exactly is TIK? Is it the Realm ephemeral key? It is unspecified what does TIK correspond to in standard TLS? Is it the DH key-pair or something derived from that? The following statement does not match sign(TIK,hs) in Fig. 8 where apparently a signing request is sent from Server to the Attestation Service.
The server then signs the handshake transcript with the (attested) identity key
The precise meaning of attest_key(nonce,TIK) needs to be clarified. Apparently, only a nonce needs to be forwarded by the Server to the Attestation Service and TIK remains with the Attestation Service only.
Some editorial/general comments:
Fig. 8: Conventionally, in confidential computing, the Verifier is on the right. Please consider following this convention (i.e., moving Client and Verifier to the right of Server) for better readability.
4th paragraph: It is unclear from the text who exactly is the attester: TEE-hosted confidential workload or TLS Server or both?
Replace "kinds of evidence" by "evidence types" for consistency.
The title "Cloud Confidential Computing" seems strange. I think "Confidential Computing" is sufficient.
The protocol flow is significantly missing the design rationale and description, for example, the following important symbols are not defined in the text:
TIK
,CAB
,hs
andsig
. Fig. 8 and its notations are very confusing. Who ownsTIK
? The following questions assume it is withAttestation Service
.Does
Attestation Service
in Fig. 8 correspond to TEE-hosted confidential workload (e.g., Realm)?Which entity in the CCA model does
Server
correspond to?Is
sig
representing the signature? Clarify in text.Is
hs
the handshake transcript? Clarify in text.Are
CAB
,KAT
andPAT
as defined in I-D.bft-rats-kat? If yes, then specify in the text.The notation
sign(TIK,hs)
is very confusing. Specifically, it is not clear what exactly is sent on the wire. Onlyhs
may be sent in this case to be signed by TIK from Attestation Service.What exactly is
TIK
? Is it the Realm ephemeral key? It is unspecified what doesTIK
correspond to in standard TLS? Is it the DH key-pair or something derived from that? The following statement does not matchsign(TIK,hs)
in Fig. 8 where apparently a signing request is sent from Server to the Attestation Service.The precise meaning of
attest_key(nonce,TIK)
needs to be clarified. Apparently, only a nonce needs to be forwarded by the Server to the Attestation Service andTIK
remains with the Attestation Service only.Some editorial/general comments: