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

[Muhammad Usama Sardar <[e-mail]>]

Hi Yaron,

I wholeheartedly agree with Ekr. We -- as WG -- should follow our 
charter and respect our agreement with TLS WG. In particular, please 
note [0] and the following discussion where we explicitly discussed 
addition of messages and modifications of key schedule at chartering 
time. Anyway, I have proposal within the scope of charter in 
post-handshake attestation which I believe is quite secure. Do you see a 
possibility to make intra-handshake attestation secure /within the scope 
of charter/? If you have proposals in intra-handshake attestation 
/within the scope of charter/, I am happy to verify it for you as well. 
We should mutually work on refining the proposals within the scope of 
charter.

About the current draft: Even within the TLS WG, there is no draft to my 
knowledge which has gone to the extent of adding a new message to the 
handshake. On top of that, modifying the key schedule is another source 
of complexity which requires /computational/ security analysis in 
addition to /symbolic / security analysis.

Speaking as a contributor to the TLS WG and someone who has been doing 
the formal proofs for TLS WG to get drafts through the FATT process: 
Unfortunately, this draft is proposing an immense amount of complexity 
-- a blender of everything from PAKE to EKU to adding messages to key 
schedule modifications -- and may break most (if not all) existing 
formal proofs done for TLS. Who will redo all the proofs?

On 10.01.26 11:56, Yaron Sheffer wrote:
> 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.
Now that it has been established that it is out of scope of charter, 
please focus on proposing solutions within the charter.
> 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.
Why do you need TLS record protocol at application level? I believe 
security should hold even if there is no record protocol. Please show me 
a concrete attack on my post-handshake attestation proposal.
> 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.
You may be right from engineering perspective, but I strongly disagree 
from security perspective. We have a formal proof that post-handshake 
attestation provides the strongest level of binding.
> 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.

Sec. 3.2 is mostly making strawman claims. The very first sentence is 
wrong. Adding new message and changing key schedule is not 
"lightweight". As mentioned above, it's one of the most significant 
changes to TLS that I am aware of. Even for PQ, TLS WG didn't go towards 
adding new messages. From a formal perspective, calling it 
"lightweight", "minimal integration" and "minimal impact" is just 
immensely wrong.

2 fine points on Sec. 3.2:

 1. /Independent handshake messages/: Does transcript hash not cover the
    Attestation message? If it does, the "independence" claim is
    trivially wrong. To justify your claims, please describe the
    property formally and show me an independence proof.
 2. /Independent key derivation/: To justify your claims, please
    describe the property formally and show me an independence proof.

Thanks.

-Usama

[0] https://mailarchive.ietf.org/arch/msg/seal/wTFq1w13d6Y7nl9KPDiwNQLbO6k/