[Seat] Re: draft-fossati-seat-early-attestation and the charter

[Yaron Sheffer <[e-mail]>]

Hi Eric,

I fully agree with your specific point and the broader point you are raising: the charter was crafted specifically to preclude this kind of solution.

Having said that, I believe a post-handshake solution for the SEAT use cases would require a re-development at the application level of both the TLS handshake message structure  (which arguably is what RFC 9261 is doing), as well as the TLS record protocol. The latter IMO is needed if we are to provide freshness/re-attestation for long running connections. So even if a post-handshake solution can be made to work, I don’t think it’s the better option from either an engineering or a security perspective.

Lastly, please read Sec. 3.2 of the draft [1] which tries to clarify why this proposal is logically an overlay on top of the TLS handshake rather than a change to it. In other words, even if the protocol fails to deliver on attestation, at worst our security reduces to a plain TLS handshake.

Thanks,
      Yaron

[1] https://www.ietf.org/archive/id/draft-fossati-seat-early-attestation-00.html#name-integration-into-the-tls-ha

From: Eric Rescorla <[e-mail]>
Date: Saturday, 10 January 2026 at 3:24
To: [e-mail] <[e-mail]>
Subject: [Seat] draft-fossati-seat-early-attestation and the charter

Hi folks,

I took a quick look at this draft. I don't have an opinion
about the security of the mechanisms defined in this draft,
but it plainly violates the following clause in the charter:

   The attested (D)TLS protocol extension will not modify the (D)TLS
   protocol itself. It may define (D)TLS extensions to support its
   goals but will not modify, add, or remove any existing protocol
   messages or modify the key schedule.

This draft adds a new message (Attestation) and extends the
key schedule.

More broadly, the point of this text in the charter was to draw a
clear boundary between this WG and TLS proper, which means that you
need to restrict yourself to the normal TLS boundaries, in this case
extensions and exporters.

-Ekr