(Adding the correct email of expat BoF)(Also adding RATS since at least my current reply relates more to RATS than TLS; and folks there may have something to add)
Thank you once again Ekr. This is insightful and timely. We will discuss this tomorrow in the Hackathon. The issue is tracked here [1]. Some initial thoughts inline:
On 18.07.25 19:35, Eric Rescorla wrote:
I've now had a chance to look at this draft. At a high level I have the same concerns I expressed over draft-fossati-tls-attestation, which is to say that it unclear what actual security properties that attestation provides.
That's a fair point and this time as an author, I fully acknowledge this shortcoming in our draft. The draft is in early stages. A formal analysis is ongoing to better characterize the security properties.
In short, remote attestation will provide Claims about:
1. Platform state
* Platform is genuine (and not simulated or emulated).
* Platform is up to date (with all security patches).
2. Workload state
* Measurements (hashes) of code and memory are as expected.
And the security properties are:
* Integrity of Claims (Claims are not modified)
* Freshness of Claims (Claims are not stale)
This is completely complementary to what TLS provides:
1. Service host authenticity
2. Extended CA validation
3. Other PKI policy checks
and the security properties of TLS are well-defined, e.g., machine
identity, server authentication.
Hence, we want to preserve the standard TLS properties and in addition, provide guarantees on the state of the platform and workload.
This draft is even more vague about this question. I appreciate that these properties are dependent on the precise configuration of the peer endpoint, and so there are presumably some specific assertions which need to appear in the attestation that describe that configuration, but I think the responsibility of this kind of draft is to explain what the implications of various choices are.
Claims mentioned above are the assertions. I am not sure what "various choices" mean here. Does it mean something like: what if I send only latest /Workload state /and older /Platform state/ for a slight performance gain? or something else? Please clarify.
[...] As you are sending CertificateRequest and/or ClientCertificateRequest,Thank you for the concrete references to the relevant sections. We'll read the pointed sections carefully, discuss it and get back to you on this.that is where the offer has to appear. IOW, the correct design is to define only one extension, "cmw_attestation", which appears in CertificateRequest or ClientCertificateRequest respectively.
One more editorial point: you repeatedly refer to this as "post-handshake", but that's more properly used to refer to the mechanism in S 4.6.2 of RFC 8446. This mechanism isn't in TLS at all, but rather in the application protocol but bound to TLS.
Agree, we will fix this. Usama [1] https://github.com/tls-attestation/exported-attestation/issues/23
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
