Thank you Ekr. This is very valuable input for the formal analysis.
The challenge from formal analysis perspective is that the architectural details of Trusted Execution Environments (TEEs) make it much more complicated. Ignoring these architectural details leads to an analysis which is of less practical value.
As a historical note, Chris Patton proposed to use RFC 9261 at IETF 120, and we started exploring that option which resulted in draft-fossati-tls-exported-attestation. We found exported authenticators to be a more reasonable way forward, both from TLS and remote attestation perspective. In particular, using exported authenticators avoids the diversion attacks I presented in last TLS meeting, namely a single broken machine could break the security of all users. Exported authenticators also avoid invasive changes to TLS protocol, requiring only a single extension flag to indicate (in CH) and acknowledge (in EE) support for this functionality, and the rest is handled at the application layer.
So we would welcome feedback from you, TLS and UFMRG on draft-fossati-tls-exported-attestation as well.
Some responses inline: On 16.07.25 22:41, Eric Rescorla wrote:
Sure, I completely agree. We have ongoing formal analysis which will help fill this gap. I will present this in UFMRG to seek feedback.# Clarity about the guarantees This draft needs to be a lot clearer about what exactly the peer is able to infer when it receives an attestation.
# Negotiation Design The design here seems oddly asymmetrical. Specifically: Server -> Client Attestation:
We call this "(TLS) Server as (RATS) Attester"
I assume by preferences, you mean preferences for RATS Evidence format (i.e., the format in which Evidence is presented).- The client expresses its preferences in CH
- The server provides its response in CERT
I think there might be a misunderstanding here. If the preferences mean as above, then its response (cf. evidence_request in Fig. 2) is already given in EncryptedExtensions (EE).
The negotiation is already complete in EE. That is, Certificate message itself does not participate in negotiation.
Certificate message then conveys the RATS Evidence in a format that was negotiated in CH and EE.
Client -> Server Attestation:
We call this "(TLS) Client as (RATS) Attester"
I am a bit confused here. Does CR mean CertificateRequest? Are you proposing that the Server responds its selected Evidence format in CertificateRequest message rather than EE? Could you please clarify this a little more?- The client expresses its capabilities in CH - The server tells the client what it wants in EE - The client then provides its response in CERT Why not instead have a symmetrical design for the Client -> Server direction where the server uses CR.extensions (with the same information that the client would have put in CH). This is how we do ordinary client authentication.
# Certificates You support two designs here: - Attestation only (S 6.1) - Attestation along with X.509 certificates (S 6.2) The first This adds a lot of complication to the CERT message because sometimes you need to carry the attestation information in an extension and sometimes it goes in the main data. That seems unfortunate because it adds complexity. I would suggest that instead for attestation-only use a raw public key. This unifies the logic, in that in either case you extract the public key for the TLS handshake from Certificate and then verify it against the attestation_evidence in the extension.
Please note that there are two different keys: * Long-Term Key: It is bound to the machine's long-term identity. * Ephemeral Key: It is a self-asserted key generated within the Trusted Execution Environment. Usama
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
