Re: [Rats] errata against RATS architecture

[Muhammad Usama Sardar <[e-mail]>]

Hi Michael,

Well, since you started a new thread, it needs some context now (which 
was clear in the previous thread with subject TDX and AMD). So the 
context in whole of my email would be confidential computing.

Some history before jumping to errata: [1] which the authors did not 
have any answer to but still continued the claim "neutral towards 
processor architectures" till the published RFC9334. Hence, with this 
claim, confidential computing is certainly in scope.

On 10.01.24 20:29, Michael Richardson wrote:
> It seems to me that the architectural split allows for multiple parties to
> run Verifiers (and not just the manufacturer).  This opens the market for
> Verifiers that can be verified.
Who verifies the Verifier that verifies the Verifier? or put simply, the 
question is how exactly would the Relying Party verify the first Verifier?
> Yet, you say say that the document is somehow fundamentally broken?
> I re-read your errata, and I don't agree it's well-formed errata.

Without a proper solution to my above question, the document just shifts 
the focus from attester to another verifier or from one verifier to 
another verifier, and is thus incomplete. Now you could have N number of 
verifiers, each verifying the next verifier in stage. But where does 
this recursion end? You just have to trust the first verifier, right? 
The following statement in Errata tries to cover this:

 > The solutions presented in the standard are not always complete and 
precise. For example, in §11, if the Verifier's own Attestation Results 
are generated by the Verifier's Verifier, it leads to recursive problems.

Now about the architecture, there is very little scientific 
justification of why this architecture is more suitable than 
alternatives, e.g., the one where the verifier and relying party are 
collapsed, as mentioned by Dionna.

There is one standard RFC9334, and there is another draft for anonymous 
attestation [2] and then there is a separate draft for explaining what 
endorsements are. Then there will be another document for local 
attestation because it is an important part of SGX and TDX remote 
attestation and not covered by RFC9334. Couldn't all of that be in a 
single standard?

Moreover, architecturally-defined attestation by itself - without 
additional mechanisms - does not provide authentication property (see 
formalization in [3]): something which is missing in the security 
considerations of RFC9334. Intel's approach to provide this 
authentication is to compose remote attestation protocol with TLS 
protocol, named as RA-TLS [4], which is widely used in industrial 
solutions such as Gramine and SGX SDK. The idea is to use generate an 
Evidence before starting TLS handshake and send this Evidence as an 
extension to the Certificate message. CertificateVerify message then 
contains the signature over handshake messages using the ephemeral key 
generated within the TEE (rather than the LTK). The problem is that it 
leads to replay attacks, as the same Evidence can be replayed in 
multiple sessions.

[1] https://mailarchive.ietf.org/arch/msg/rats/qYUQ1C5-8blE4KzF7PnYW-pXrUQ/

[2] https://datatracker.ietf.org/doc/draft-ietf-rats-daa/

[3] https://ieeexplore.ieee.org/document/10373038

[4] https://arxiv.org/pdf/1801.05863.pdf

Regards,

Usama