[Seat] Re: Clarification of charter re forbiddden TLS protocol changes

[Ionut Mihalcea <[e-mail]>]

Sure, and this touches on one of my points from last week, that we need to draw the line more clearly between working groups. Saying this not as a barrier, but as a separation of concerns. We can then have work done in the TLS WG to assess and provide the necessary mechanisms that SEAT drafts require. We already use extensions that went through that exact process, be it exported authenticators or extended key update.

Thanks,
Ionut

From: Eric Rescorla <[e-mail]>
Date: Monday, 27 July 2026 at 14:14
To: Ionut Mihalcea <[e-mail]>
Cc: Markus Rudy <mr=[e-mail]>; seat <[e-mail]>; nd <[e-mail]>
Subject: Re: [Seat] Re: Clarification of charter re forbiddden TLS protocol changes

While it's possible that the charter narrowly permits this, I think it's pretty clearly contrary to the spirit of the charter, which is to restrict SEAT's use of TLS to defined exposed interfaces. I would expect that if the WG decided to do something like you suggest you would get objections in IETF LC or whenever TLSers became aware of it; I would most likely be one of the objectors.

-Ekr



On Mon, Jul 27, 2026 at 5:38 AM Ionut Mihalcea <[e-mail]<mailto:[e-mail]>> wrote:
Hi Markus,

See below with [IM].

From: Markus Rudy <mr=[e-mail]<mailto:[e-mail]>>
Date: Monday, 27 July 2026 at 12:11
To: seat <[e-mail]<mailto:[e-mail]>>
Subject: [Seat] Clarification of charter re forbiddden TLS protocol changes

Hi SEAT,

I’ve seen the following charter requirement cited on-list from time to time:

> 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.

Does this requirement apply to pure observation of the TLS handshake and deriving an attestation binder from the observations?

Do we consider read-only access to TLS handshake internals (messages, message log, intermediate derived keys) as a violation?

[IM] Trying to answer both questions from above, I realised my view was incomplete. My initial take was that, as long as we don't modify the internals (state machine, key schedule...) we're good, and when adding extensions to the protocol we can define them to make use of things that are available only as internal APIs. But I don't think this is valid - with that approach you could just read keys and expose them in the extension, which would conflict with the security guarantees of TLS. Perhaps we need to refine that statement in the charter. I'm curious whether it's already defined somewhere what internal state can be accessed securely when defining extensions.

Can charter-conforming protocols only depend on explicit TLS APIs for external consumption, such as EKM?

Cheers, Markus


_______________________________________________
Seat mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
Seat mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>