[Seat] Re: New Version Notification for draft-fossati-seat-early-attestation-00.txt

["jiangyuning (A)" <[e-mail]>]

Dear authors,

Thank you for the recent submission of this draft.

Building on my previous email and the role mapping discussion in GitHub Issue #23 [1], where I analyzed attester roles (client, server, or mutual) across the use cases [2], I've now extended it with a detailed mapping of use cases to intra/post/hybrid needs.

I believe both intra-handshake (as in [3]) and post-handshake (as in [4]) solutions are essential. Not all use cases can be addressed by one approach alone, some benefit from intra for efficient setup-phase verification, while others require post for dynamic, runtime, or operation-triggered freshness without renegotiation. For example:

  *   Runtime Secret Provisioning and Attestation of Network Functions: this involves one-time attestation during initial bootstrapping (e.g., a workload or IoT device proving its state to fetch secrets). Also, in order to get secrets such as database credentials, post-handshake is also needed.
  *   Secure Multi-Party Computation (MPC): this is mutual setup-phase attestation; no explicit runtime elements.
  *   High-Assurance Command Execution and High-Assurance Operation Execution: this prefers post-handshake for fresh evidence over existing connections.

I'd appreciate help from the use case authors (as in [2]) and authors in intra-handshake (as in [3]) and post-handshake (as in [4]) solutions to further analyze and confirm which scenarios require intra, post, or a hybrid approach.
Looking forward to your thoughts on this!

Best regards,
Yuning

[1] https://github.com/tls-attestation/use-cases-and-properties/issues/23
[2] https://datatracker.ietf.org/doc/draft-mihalcea-seat-use-cases/
[3] https://datatracker.ietf.org/doc/draft-fossati-seat-early-attestation/
[4] https://datatracker.ietf.org/doc/draft-fossati-seat-expat/

From: Yogesh Deshpande <[e-mail]>
Sent: Friday, January 9, 2026 9:25 PM
To: tirumal reddy <[e-mail]>; Yaron Sheffer <[e-mail]>
Cc: [e-mail]; Tirumaleswar Reddy.K <[e-mail]>; Ionut Mihalcea <[e-mail]>; Thomas Fossati <[e-mail]>
Subject: [Seat] Re: New Version Notification for draft-fossati-seat-early-attestation-00.txt

I fully agree and support view presented by Tiru below!!

From: tirumal reddy <[e-mail]<mailto:[e-mail]>>
Sent: Friday, January 9, 2026 12:49 PM
To: Yaron Sheffer <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Tirumaleswar Reddy.K <[e-mail]<mailto:[e-mail]>>; Ionut Mihalcea <[e-mail]<mailto:[e-mail]>>; Thomas Fossati <[e-mail]<mailto:[e-mail]>>; Yogesh Deshpande <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Seat] Re: New Version Notification for draft-fossati-seat-early-attestation-00.txt

I would like to note that the intra-handshake and post-handshake attestation drafts are designed to achieve the same core security properties, including binding attestation to the TLS connection and TLS identity. Both drafts support re-attestation and prevent relay attack.

Each draft has its own advantages and disadvantages, and I believe both approaches are useful for the WG to evaluate.

Best Regards,
-Tiru

On Fri, 9 Jan 2026 at 17:38, Yaron Sheffer <[e-mail]<mailto:[e-mail]>> wrote:
We have just submitted -00 of this draft, our proposed intra-handshake protocol to address the SEAT use cases. The editor team is Tiru, Ionut, Thomas, Yogesh and myself.

This is a massive rewrite of the previous draft-fossati-tls-attestation with many changes that resolve security and other concerns that were raised with that draft. Among others, we decoupled attestation from certificate messages and redefined the cryptographic binding between the TLS connection and attestation artifacts. However, from an application’s point of view, the new protocol preserves the simplicity of the intra-HS approach.

This is a lot of reading, so let me point out some key sections:

  *   The last part of the Introduction describes the advantages we see with the intra-HS approach.

  *   Sec. 3.2 describes the full set of extensions we propose to the TLS protocol, and is an informal argument why, despite meddling with the handshake, we are not “breaking TLS”.

  *   Sec. 5.3 goes through the details of one of the top use cases: server attestation.

  *   Sec. 5.8 describes how the cryptographic binding in this protocol addresses a relay attack that’s been discussed on this list.

  *   And Sec. 7.2 shows how we deal with attestation freshness, even for long-standing TLS connections.

Thanks,
      Yaron

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Friday, 9 January 2026 at 13:43
To: Tirumaleswar Reddy.K <[e-mail]<mailto:[e-mail]>>, Ionut Mihalcea <[e-mail]<mailto:[e-mail]>>, Ionut Mihalcea <[e-mail]<mailto:[e-mail]>>, Thomas Fossati <[e-mail]<mailto:[e-mail]>>, Tirumaleswar Reddy <[e-mail]<mailto:[e-mail]>>, Yaron Sheffer <[e-mail]<mailto:[e-mail]>>, Yogesh Deshpande <[e-mail]<mailto:[e-mail]>>, Yogesh Deshpande <[e-mail]<mailto:[e-mail]>>
Subject: New Version Notification for draft-fossati-seat-early-attestation-00.txt
A new version of Internet-Draft draft-fossati-seat-early-attestation-00.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:     draft-fossati-seat-early-attestation
Revision: 00
Title:    Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
Date:     2026-01-09
Group:    Individual Submission
Pages:    34
URL:      https://www.ietf.org/archive/id/draft-fossati-seat-early-attestation-00.txt
Status:   https://datatracker.ietf.org/doc/draft-fossati-seat-early-attestation/
HTML:     https://www.ietf.org/archive/id/draft-fossati-seat-early-attestation-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-fossati-seat-early-attestation


Abstract:

   The TLS handshake protocol allows authentication of one or both peers
   using static, long-term credentials.  In some cases, it is also
   desirable to ensure that the peer runtime environment is in a secure
   state.  Such an assurance can be achieved using remote attestation
   which is a process by which an entity produces Evidence about itself
   that another party can use to appraise whether that entity is found
   in a secure state.  This document describes a series of protocol
   extensions to the TLS 1.3 handshake that enable the binding of the
   TLS authentication key to a remote attestation session.  This enables
   an entity capable of producing attestation Evidence, such as a
   confidential workload running in a Trusted Execution Environment
   (TEE), or an IoT device that is trying to authenticate itself to a
   network access point, to present a more comprehensive set of security
   metrics to its peer.  These extensions have been designed to allow
   the peers to use any attestation technology, in any remote
   attestation topology, and to use them mutually.



The IETF Secretariat
_______________________________________________
Seat mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.