On Wed, Jul 16, 2025 at 4:00 PM Muhammad Usama Sardar < muhammad_usama.sar...@tu-dresden.de> wrote:
> 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. > Thanks for the information. I have read that draft, but wasn't sure which version you were favoring. I'll try to provide some comments. > # Negotiation Design > > The design here seems oddly asymmetrical. Specifically: > > Server -> Client Attestation: > > We call this "(TLS) Server as (RATS) Attester" > OK. > - The client expresses its preferences in CH > > I assume by preferences, you mean preferences for RATS Evidence format > (i.e., the format in which Evidence is presented). > Yes. What's in "evidence"request". - 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. > Right. However, the actual data is in CERT. 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" > > - 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. > > 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? > Ah, I see the point you are making, which is that the Certificate message has no location for providing the chosen format. I believe if you take my suggestion below, that will resolve this issue, as you don't need to negotiate it, just add the appropriate attestation in an extension in CertificateEntry. > # 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. > > I haven't studied the design of the RATS objects closely, but as I understand the situation, from the perspective of TLS the material in the attestation is a signature over a long-term TIK which is then used to sign the TLS handshake transcript. Assuming that's correct, then I believe that what I am suggesting here will work. -Ekr
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
