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

[Nathanael Ritz <[e-mail]>]

Hello,

I have comments to share. Comments are offered below with [NR]:

On Wed, 5 Aug 2026 at 08:50, Muhammad Usama Sardar <
[e-mail]> wrote:

> Hi Tiru,
>
> What I have heard from many participants is the desire for a security
> property that this hybrid draft claims to satisfy which post-handshake
> alone cannot satisfy. I could not find such a property in -06.
>

[NR]: I have not seen any technical substance in this inquiry. I am curious
what is prompting the same set of participants to repeatedly persist this
line of inquiry on-list, and towards what constructive purpose?

On Wed, 5 Aug 2026 at 08:50, Muhammad Usama Sardar <
[e-mail]> wrote:

> I've seen the diff from -04 which is the last version I have previously
> formally analyzed.


[NR]: I am not aware of a formal model by Sardar et al. which demonstrates
the security properties and mechanisms of
draft-fossati-seat-early-attestation-04 that has been released to the
public. If such a model exists, I hope that it is shared with the
community.

On Wed, 5 Aug 2026 at 08:50, Muhammad Usama Sardar <
[e-mail]> wrote:

> Only my comment on "Post-handshake server authentication" was addressed.
> All my other comments [0] are unaddressed, including CVE-2026-33697 still
> being applicable here.
>

[NR]: I do not believe there is demonstrable evidence that CVE-2026-33697
applies to draft-fossati-seat-early-attestation-06. Perhaps the repetition
of the same arguments without disclosed evidence stems from a fundamental
misunderstanding of applied cryptography concepts such as authenticated key
exchange and channel binding?

[NR]: Helpfully, in a seperate exchange on the TLSWG [0], Dr. Sophie
Schmieg (Head of Cryptography and Staff Information Security Engineer at
Google) recently endorsed and shared a link to "A Graduate Course in
Applied Cryptography" by Boneh and Shoup [1]. I am being particularly
verbose about Sophie's background here because the resource shared at [1]
is both detailed and complex. However, as a WG within the SEC area of the
IETF, the work mandated by the SEAT charter sits firmly within the domain
of applied cryptography. With that background established, I'll return to
my points on authenticated key exchange and channel binding below.

[NR]: The detailed discussion on authenticated key exchange and channel
binding happens within chapter 21 (starting on page 869). On Page 897,
Section 21.9.6, Paragraph 3, the textbook establishes the rule for
computing bindings:

  > "...a user instance should compute its channel binding
     based only on its role, and on the information it sends
     and receives over the network during the execution of
     the key exchange protocol (all of this information is
     present in the network communication log)"

[NR]: That is the precise mechanism that the -06 draft proposes.
Furthermore, On Page 884, Section 21.8, Paragraph 3, the textbook lists
examples of secure channel bindings. For Protocol 'AKE4', the binding is
simply '(pk, c)'. That is to say, it includes the public key and the
ciphertext; the secure example does *not* mandate reference to the
underlying session key.

[NR]: If Usama and others have discovered concrete counter-examples against
the security of such examples and mechanisms, I implore them to share the
technical details, rather than repeating what appears to be the same
argument over again, based on intuition and personal belief alone.

Cheers,
Nathanael

[0] https://mailarchive.ietf.org/arch/msg/tls/evs5vqvK7kTEFHCPdnqM7Xf3Yyk/

[1] https://toc.cryptobook.us/book.pdf

-------------------
From: Muhammad Usama Sardar <[e-mail]>
Date: Wed, 5 Aug 2026 at 08:50
Subject: [Seat] Re: FW: New Version Notification for
draft-fossati-seat-early-attestation-06.txt
To: <[e-mail]>


Hi Tiru,

What I have heard from many participants is the desire for a security
property that this hybrid draft claims to satisfy which post-handshake
alone cannot satisfy. I could not find such a property in -06.

I've seen the diff from -04 which is the last version I have previously
formally analyzed. Only my comment on "Post-handshake server
authentication" was addressed. All my other comments [0] are
unaddressed, including CVE-2026-33697 still being applicable here.

Best,

-Usama

[0] https://mailarchive.ietf.org/arch/msg/seat/2HfF4JjZbJhw-HJo1GbVTkUmeVU/


_______________________________________________
Seat mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

-------------------
From: tirumal reddy <[e-mail]>
Date: Wed, 5 Aug 2026 at 07:23
Subject: [Seat] FW: New Version Notification for
draft-fossati-seat-early-attestation-06.txt
To: <[e-mail]>


Hi all,

We have posted -06 of draft-fossati-seat-early-attestation. This revision
addresses the relay/replay concerns discussed in the WG, and explains the
relay resistance of the design, which binds the Evidence to the connection
transcript and to the attester's TLS identity key (i.e., the public key of
the attester's end-entity certificate used for authentication). .

Diff from -05:
https://author-tools.ietf.org/iddiff?url2=draft-fossati-seat-early-attestation-06


How the design addresses the attacks discussed:

1) Per-connection binding (Section 8.1). The attestation binder is anchored
to the ClientHello...ServerHello transcript checkpoint. Both peers
contribute fresh key-exchange material, so neither side alone controls the
transcript and the resulting binder is unique to the connection (two-sided
uniqueness). Evidence generated in one connection therefore cannot be
replayed in another.

2) Transcript vs. Exporter (Appendix B). We discuss why the binder is
anchored to the transcript rather than to an exported value. EKM is not
available during the handshake, when early attestation is produced; the
early_exporter_secret is only meaningful under a PSK and carries no server
contribution, so it does not provide two-sided uniqueness.

3) No change to the key schedule. Binder derivation uses HKDF to produce
binding values, not keying material. It runs alongside the standard key
schedule without modifying any existing derivation, consistent with the
SEAT charter.

4) Existing TLS APIs (Appendix C). The ClientHello...ServerHello transcript
can be computed with existing TLS APIs, requiring no new interface.

5) Privacy (Section 9.1). Added a subsection on server attestation to
unauthenticated clients, with mitigations via the Passport model and
selective disclosure.

Reviews and comments are welcome.

Thanks,
-Tiru, Yaron, Ionut, Thomas and Yogesh

-----Original Message-----
From: [e-mail] <[e-mail]>
Sent: Wednesday, August 5, 2026 4:08 PM
To: K Tirumaleswar Reddy (Nokia) <[e-mail]>; Ionut
Mihalcea <[e-mail]>; Ionut Mihalcea <[e-mail]>;
Thomas Fossati <[e-mail]>; K Tirumaleswar Reddy (Nokia) <
[e-mail]>; Yaron Sheffer <[e-mail]>;
Yogesh Deshpande <[e-mail]>; Yogesh Deshpande <
[e-mail]>
Subject: New Version Notification for
draft-fossati-seat-early-attestation-06.txt


CAUTION: This is an external email. Please be very careful when clicking
links or opening attachments. See the URL nok.it/ext for additional
information.



A new version of Internet-Draft draft-fossati-seat-early-attestation-06.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:     draft-fossati-seat-early-attestation
Revision: 06
Title:    Using Attestation in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS)
Date:     2026-08-05
Group:    Individual Submission
Pages:    32
URL:
https://www.ietf.org/archive/id/draft-fossati-seat-early-attestation-06.txt
Status:
https://datatracker.ietf.org/doc/draft-fossati-seat-early-attestation/
HTML:
https://www.ietf.org/archive/id/draft-fossati-seat-early-attestation-06.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-06

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 TLS extension that
   enables the negotiation and 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.
   This extension has 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]