[TLS] Re: Comments on draft-fossati-tls-attestation-09.txt

[Muhammad Usama Sardar]

Please see inline:

On 17.07.25 02:57, Eric Rescorla wrote:

Thanks for the information. I have read that draft, but wasn't sure which version you were

favoring.

Please accept my apologies for not announcing clearly on the list. The super set of authors of both drafts have a full consensus that draft-fossati-tls-exported-attestation is a preferable option.

I'll try to provide some comments.

Thank you. For comments on draft-fossati-tls-exported-attestation, please keep attested-...@ietf.org also in the loop because this is what the proposed WG will use as a starting point.

Right. However, the actual data is in CERT.

Correct, but just to clarify, my point was that in both cases (Client as Attester and Server as Attester), the negotiation is symmetric and ends in EE. So I don't see any asymmetry from negotiation perspective. As I understood, your main point was about asymmetry in negotiation. You are right that the Evidence (what you call actual data) itself is in CERT but Server can no longer change its preference compared to what it announced in EE message, because that is captured as part of the running hash. In other words, the Server still has to send the Evidence in the format it announced in EE, otherwise the transcripts will not match.

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.

Yes, in draft-fossati-tls-exported-attestation, we follow what you are suggesting. There, we just use a flag extension to indicate the support and do not negotiate the formats.

    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.


transcript.

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

TIK is not necessarily long-term. TIK in the draft is used to refer to both Long-Term Key (LTK) and Ephemeral Key (EK). In draft-fossati-tls-exported-attestation, we always keep authentication via LTK, and add Evidence as an extension to the Authenticator's Certificate message whenever requested via Authenticator Request. This addresses the need for dynamic runtime state of device in long-lived connections as well. That is, one can make a request at any point in time after the handshake, and as many times as required. So I believe draft-fossati-tls-exported-attestation covers both of your comments. But we look forward to your comments on that.

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org