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

[Nathanael Ritz <[e-mail]>]

Hello!

In preparation for the upcoming meeting, I took some additional time to
review `draft-fossati-seat-early-attestation-03` in greater detail. These
are the notes I put together and thought I would share ahead of time before
the meeting.

## Strong Cryptographic Binding and Charter Alignment

As I shared earlier this month in this thread, the introduction of the
newly suggested attestation binder in the Early Attestation draft
successfully establishes strong cryptographic binding and agreement across
both TLS authentication and remote attestation properties, based on my
model. Crucially, the model I wrote maintains complete independence from
the standard TLS key schedule while demonstrating the desired security
properties. As such, I am confident that the binder achieves the
architectural separation that directly aligns with the objectives of the
SEAT charter.

## Re-attestation and Application Transparency Gaps

While the outstanding design decisions regarding re-attestation [1]
represent a significant gap, I agree ideally that re-attestation shouldn't
require direct awareness or active participation from the application
layer. To be clear, I am against leaving adopters without options. As the
FACTS proposal also defers post-handshake re-attestation to the use of
Exported Authenticators (per EXPAT), FACTS fundamentally shares this same
architectural TODO with Early Attestation. So, I don't have any specific
corrective notes for the text, but I agree that the need for a
re-attestation solution that stays entirely within the bounds of the TLS
library is needed and I am eager to explore those options in mutual support
for our specific approaches.

Cheers,

Nathanael

[1] `draft-fossati-seat-early-attestation-03` - Section 5.4, "Reattestation"

On Tue, 10 Mar 2026 at 00:44, Nathanael Ritz <[e-mail]> wrote:

> Hello Early Attestation authors!
>
> I wanted to share some direct feedback on your new draft, following a
> preliminary formalization of security properties enabled by the newly
> proposed cryptographic binder described in Section 5.1.1 of your -03
> submission.
>
> In my recent note announcing my own independent I-D submission [0], I made
> claims of machine-checked evidence, demonstrating mitigation for the
> well-known diversion and relay attacks within intra-handshake attestation
> protocols that Usama and colleagues have been sharing with the community.
> As both of our protocols address intra-handshake attestation, I was very
> curious to understand the security properties of the proposed binder, so I
> volunteered to adapt your design within the same ProVerif model structure.
>
> ---
> Adopting the language from the original Identity Crisis paper, the
> original model demonstrated that naive binding found in deployed
> intra-handshake implementations fail both G-C1 (Compound Authentication)
> and G-C2 (Compound Agreement) under single-key compromise. The new binder
> mechanism introduced in your -03 changes this result.
>
> I've shared a snippet of the results below but in plain terms:
> Based on your design within the formalization of the model, *the results
> indicate that an attacker must compromise both the TLS and Attestation
> signing keys to break the security properties for an honest Client and
> Server.* This demonstrates significantly stronger security properties than
> the original TLS-a protocol design that the original ProVerif model could
> prove:
>
> G-C1
> ```
> inj-event(ClientFinishedWithID(ID, pubTIK, pubAK, ...)) ==>
>   inj-event(PreServerFinishedWithID(ID, pubTIK, pubAK, ...)) ||
> LeakedTIK(pubTIK) — true
>
> inj-event(ClientFinishedWithID(ID, pubTIK, pubAK, ...)) ==>
>   inj-event(PreServerFinishedWithID(ID, pubTIK, pubAK, ...)) ||
> LeakedAK(pubAK) — true
>
> inj-event(ClientFinishedWithID(ID, pubTIK, pubAK, ...)) ==>
>   inj-event(PreServerFinishedWithID(ID, pubTIK, pubAK, ...)) [full key
> compromise] — false
> ```
>
> G-C2
> ```
> inj-event(ClientComp(ID_S, pubTIK, ..., dev_state))
>   ==> inj-event(PreServerComp(ID_S, pubTIK, ..., dev_state))
>    || LeakedEK(pubTIK) — true
>
> inj-event(ClientComp(ID_S, pubTIK, ..., dev_state))
>   ==> inj-event(PreServerComp(ID_S, pubTIK, ..., dev_state))
>    || LeakedAK(pubAK) — true
>
> inj-event(ClientComp(ID_S, pubTIK, ..., dev_state))
>   ==> inj-event(PreServerComp(ID_S, pubTIK, ..., dev_state))
>    [full key compromise] — false
> ```
>
> ---
> It's worthwhile to note that the queries I am referencing are based on the
> same formalization directly from Sardar et al.'s released model. Recently,
> Usama shared a point of caution with me that additional artifacts exploring
> the prevalence of relay attacks in intra-handshake attestation are
> forthcoming [2]. In that light, I would recommend that the cryptographic
> binder design proposed in your -03 submission be scrutinized as new
> resources are shared to classify the specific security properties, above
> and beyond my own iteration I am sharing today.
>
> Finally, this adaptation of your proposed cryptographic binder design was
> put together independently by me. So it is subject to my present-best
> understanding of the draft's intent and my own personal skill with the
> ProVerif tool (i.e., this is not a peer-reviewed submission). With that
> said, it is my position that the proposed design demonstrates promising
> results.
>
> The model and the results are available for review on GitHub [3], in the
> hope that may be helpful.
>
>
> Cheers,
> Nathanael
>
>
> [0]
> https://mailarchive.ietf.org/arch/msg/seat/DlxKQ-XwU7KBjU0Q2MmP_-swE8E/
>
> [1] https://github.com/CCC-Attestation/formal-spec-id-crisis
>
> [2]
> https://mailarchive.ietf.org/arch/msg/seat/Le6hXcr6l2jfHPaiprcB12Rr0bM/
>
> [3]
> https://github.com/nathanaelritz/formal-spec-id-crisis/tree/main/fossati-seat-early-attestation-03
>
> On Sun, 1 Mar 2026 at 11:06, Yaron Sheffer <[e-mail]> wrote:
>
>> In time for IETF-125, we submitted a new version of the Early Attestation
>> draft. Following is the change log:
>>
>>
>>    - Replace the Attestation message by an Attestation (certificate)
>>    extension, to bring this protocol within the requirements of the SEAT
>>    charter.
>>
>>
>>    - Define the attestation binder and decouple it from the TLS key
>>    schedule.
>>    - List multiple design options for reattestation.
>>    - Add architecture diagram for TLS stack interface with the TEE.
>>    - Add defense-in-depth guidance for measuring TEE, TLS stack, and
>>    shim.
>>    - Remove various outdated sections.
>>
>>
>> Thanks,
>>
>> Tiru, Ionut, Thomas, Yogesh and Yaron
>>
>>
>> *From: *[e-mail] <[e-mail]>
>> *Date: *Sunday, 1 March 2026 at 17:59
>> *To: *Tirumaleswar Reddy.K <[e-mail]>, Ionut
>> Mihalcea <[e-mail]>, Ionut Mihalcea <[e-mail]>,
>> Thomas Fossati <[e-mail]>, Tirumaleswar Reddy <
>> [e-mail]>, Yaron Sheffer <[e-mail]>,
>> Yogesh Deshpande <[e-mail]>, Yogesh Deshpande <
>> [e-mail]>
>> *Subject: *New Version Notification for
>> draft-fossati-seat-early-attestation-03.txt
>>
>> A new version of Internet-Draft
>> draft-fossati-seat-early-attestation-03.txt
>> has been successfully submitted by Yaron Sheffer and posted to the
>> IETF repository.
>>
>> Name:     draft-fossati-seat-early-attestation
>> Revision: 03
>> Title:    Using Attestation in Transport Layer Security (TLS) and
>> Datagram Transport Layer Security (DTLS)
>> Date:     2026-03-01
>> Group:    Individual Submission
>> Pages:    29
>> URL:
>> https://www.ietf.org/archive/id/draft-fossati-seat-early-attestation-03.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-fossati-seat-early-attestation/
>> HTML:
>> https://www.ietf.org/archive/id/draft-fossati-seat-early-attestation-03.html
>> HTMLized:
>> https://datatracker.ietf.org/doc/html/draft-fossati-seat-early-attestation
>> Diff:
>> https://author-tools.ietf.org/iddiff?url2=draft-fossati-seat-early-attestation-03
>>
>> 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 TLS
>>    extensions 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]
>> To unsubscribe send an email to [e-mail]
>>
>