Specifications of protocol for interoperable RA TLS with CA-signed certs

Context/background: Discussion during the invited talk at Intel

@monavij claimed that this new "standardized" solution of interoperable attested TLS allows CA-signed certs in addition to self-signed certs. She also mentioned that the repo has specifications, which she would like to be verified.

"Standard"

First, CCC is not a standardization body. Standardization happens in standardization bodies, such as IETF. Sure, CCC can help in doing the work required for standardization but just by having something agreed by some of the developers does not make it a "standard". There is not even an Internet-Draft on this proposal in the IETF TLS WG (the most relevant WG for standardization of this proposal), and I find it strange to claim interoperable attested TLS as a standard already.

Moreover, TLS WG requires high assurances of security and has recently introduced formal analysis as part of the adoption process to maintain these assurances. Our research and discussions in SIG show that RA-TLS is a broken protocol and it is not possible to fix it reasonably within the pre-handshake solution. I don't believe IETF TLS WG will even adopt such a broken protocol for standardization.

Please clarify in which standardization body the protocol was standardized.

CA-signed certs rather than self-signed

I checked the three provided certificates in the repo:

and had a quick check using the following command:

openssl x509 -in <certname>.pem -text

Gramine:

openssl x509 -in gramine-cert.pem -text shows:

Issuer: CN = RATLS, O = GramineDevelopers, C = US Subject: CN = RATLS, O = GramineDevelopers, C = US Validity: Not After : Dec 31 23:59:59 2030 GMT CA:FALSE

SGX SDK:

openssl x509 -in intel-sgxsdk-cert.pem -text shows:

Issuer: CN = Intel SGX Enclave, O = Intel Corporation, C = US Subject: CN = Intel SGX Enclave, O = Intel Corporation, C = US Validity: Not After : Dec 31 23:59:59 2050 GMT CA:FALSE

RATS TLS:

openssl x509 -in rats-tls-cert.pem -text shows:

Issuer: O = Inclavare Containers, CN = RATS-TLS Subject: O = Inclavare Containers, CN = RATS-TLS Validity: Not After : Feb 22 17:10:22 2024 GMT CA:FALSE

Conclusion:

Subject = Issuer -> All certs are self-signed.

As far as my memory goes, it was never mentioned in any SIG meetings about how the interoperable RA TLS proposal works with the CA-signed certs. The current specifications in the repo also do not seem to mention anything about this. A quick look at the implementations shows that they support only self-signed certs at the attester side, and some implementations allow only self-signed certs (depth = 0) at the verifier side. To consider its formal verification, we need proper specification of how it works with the CA-signed certs, at least the changes in the flow of the protocol shown in slide 11/34 in the talk.

@muhammad-usama-sardar Thanks for reaching out to us directly. You clearly misunderstood my mention of interoperable-RATLS. First, Interoperable-RATLS was designed to solve a very different problem. The only reason I pointed you to interoperable RA-TLS was because you kept referring to our original RA-TLS research paper as a spec for RA-TLS protocol. We never defined a spec or a new secure channel protocol. Our paper does not modify TLS protocol at all, but rather adds attestation support with an idea of using X509 cert extensions. The goal was easily adoptable and easy to use without needing protocol or even library updates, as standardization efforts can take years. One additional motivation was that it can also work with other X509 enabled protocols, e.g., S/MIME for messaging. This would allow us to have a unified approach to attestation across multiple use cases.

The RA-TLS approach clicked with several projects and several implementations emerged that were not interoperable. We saw a short term need to define a common format for the X509 cert extensions used by different projects and that is how interoperable RA-TLS was born and it nicely addressed that problem. At least two projects Gramine and Occlum have implemented and validated interoperable RA-TLS.

"Standard"

And you are right I may have used the term “standard” and I take that back. I agree with you there is NO standard for RA-TLS. Our goal was to establish common interoperable, easy and quickly adoptable and good practices (which we still believe). What I suggest is that we collaborate on a more explicit spec as well as on what security properties are truly required and which ones are only desirable. As with many things, it seems in this space there is room for multiple (valid) approaches.”

Subject = Issuer -> All certs are self-signed.

You are right that original white paper from 2018 includes just the self-signed certs, and all implementations use that idea. In Gramine documentation we provide environment variables to set the expiry date for certs and anyone deploying Gramine in production needs to pay attention. The values you mention are just default values, just like default signing keys are also not to be used in production. https://gramine.readthedocs.io/en/stable/attestation.html - Look for environment variables.

To consider its formal verification, we need proper specification of how it works with the CA-signed certs,

You are right. That is my whole point, you have formally verified something that is not specified at all. Since that white paper in 2018 we have thought about alternates to CA-signed certs in the contest of few other projects. Turns out we never published this idea, but it’s been implemented in few projects. So, I am happy to discuss this line of work with you.

secured_cert_provisioning

So, to wrap up, I am glad that you are contacting the original authors of the white paper. If you would like to help specify and enhance RA-TLS, then we are happy to collaborate with you and explore IETF standardization of X509 cert extensions. Please reach out to us directly to schedule a small group discussion with the original authors of RA-TLS white paper.

@monavij I appreciate clarifications and detailed answer.

Some general thoughts: My personal understanding is that you are colluding three different things:

Intel's RA-TLS
CCC Attestation SIG's Interoperable RA-TLS (the repo we are in)
Some combination of RA-TLS with Attested CSR (the design that you mentioned in the diagram above)

So let's try to precisely disentangle those to have a better mutual understanding of what exactly we are talking about. In all of my presentations, I am absolutely clear that our formalization is based on the first one, and as shown in my slide 8/34, we filled the remaining gaps from the implementations and community input/domain experts (such as CCC Attestation SIG, where Ned Smith and Dan Middleton are regular participants, and IETF).

Unlike one of its original objectives "support for per-session evidence freshness" (see slide 5 of Shanwei's proposal), as of today "interoperable RA-TLS" still seems to have the same protocol as the RA-TLS white paper. The issue then is that all of the security concerns are still going to be applicable on this design. Since Shanwei has retired, for the SIG it is a "dead" project as we haven't heard about this project lately. Has there been any progress on the support for per-session evidence freshness?

Now about your specific comments:

First, Interoperable-RATLS was designed to solve a very different problem.

That's not correct. In Dmitrii's presentation in March 2022, I already raised the concern about weak channel bindings. Until August/September 2022, Shanwei had already acknowledged this concern and when he proposed the project, "support for per-session evidence freshness" was also part of the objectives (see his slide 5). Has there been any progress on that front?

you kept referring to our original RA-TLS research paper as a spec for RA-TLS protocol.

From a formal perspective, I don't think this makes much difference except that having no specs is even worse than having incomplete and outdated specs. Also, having no spec does not mean one should wait forever for the spec to be available to start formal verification.

We never defined a spec or a new secure channel protocol. Our paper does not modify TLS protocol at all, but rather adds attestation support with an idea of using X509 cert extensions.

Better late than never. Why not publish the specs of both RA-TLS and interoperable RA-TLS now? Or did you mean that they do not exist internally within Intel as well? In any case, formal analysis of standard TLS assumes CA-signed certificates and that is clearly not the case here. Moreover, addition of attestation support requires new formal analysis with additional properties, such as integrity and freshness of evidence.

At least two projects Gramine and Occlum have implemented and validated interoperable RA-TLS.

Just as a side note: The original goal as proposed to the SIG was to have interoperability for Gramine, RATS-TLS, Open Enclave and SGX SDK.

And you are right I may have used the term “standard” and I take that back.

Thank you for clarification.

The values you mention are just default values

Sure, and this is how I always mention it. Anyway, just to be more explicit, I have added "Default" to the caption of table for future. But the problem still is that reducing the validity can reduce the window of attack, but never completely eliminate it. That's why we call it mitigation rather than a fix.

That is my whole point, you have formally verified something that is not specified at all.

As I said, having no spec does not mean one should wait forever for the spec to be available to start formal verification, specially for security-critical applications. Sure, we had to take the extra pain of looking at the implementations of these projects to be sure. We also discussed it with the domain experts in the CCC Attestation SIG and IETF. So we are pretty much confident on the formal specification we have. I think a more important thing to discuss is: do you see anything different as compared to the one shown on my slide 11/34? Again in your answer, please clarify separately for RA-TLS and interoperable RA-TLS.

but it’s been implemented in few projects

Are you referring to Veracruz and Enarx mentioned on my slide 28/34? To my knowledge, Attested CSR currently does not support freshness. So the design you mentioned in your figure still suffers from the same "per-session evidence freshness" problem.

We already collaborate with Ned Smith in the work exploring the design space of attested TLS and the relevant properties, and would be happy to discuss mutual collaboration with you, once we have more clear answers to above questions.

CCC-Attestation / interoperable-ra-tls