[Seat] Re: I-D Action: draft-ietf-seat-use-cases-01.txt

[Ionut Mihalcea <[e-mail]>]

Below with [IM]

From: Chengxin Huang <[e-mail]>
Date: Saturday, 19 September 2026 at 01:49
To: Ionut Mihalcea <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; nd <[e-mail]>
Subject: Re: [Seat] Re: I-D Action: draft-ietf-seat-use-cases-01.txt

Dear all,

Ionut's work [ionut-work], intra-handshake.fail [intra-fail] and other GHSAs that helped settle the debate are also not reflected in draft-ietf-seat-use-cases-01.txt.

[IM] If the debate was settled, we wouldn't really be here. Since we're since debating this (although, debating is a strong word, given that you disregard all arguments provided), it is by definition not settled.

Basically you do one TLS for "authenticating identity or key". Then do another TLS for early attestation with "existing authenticated identity or key". Then you keep doing re-attestation on top of these TLS connections.

The only advantage I previously thought early attestation had is unfortunately not present either.

[IM] The core benefit and argument for early attestation (at least in my appreciation) was, and remains, a more thorough separation of remote attestation from application level code. Thanks to Nathanael's work, we now also know that it helps with tying the application traffic secrets to the attestation credential that was accepted by the RP - though we need more work to understand the security benefit better.

Best regards,
Chengxin Huang

[ionut-work] https://www.usenix.org/system/files/atc25-weinhold.pdf
[intra-fail] https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS

On Sat, Sep 19, 2026 at 8:42 AM Ionut Mihalcea <[e-mail]<mailto:[e-mail]>> wrote:
Below with [IM]

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 17 September 2026 at 20:54
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: Ionut Mihalcea <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Seat] Re: I-D Action: draft-ietf-seat-use-cases-01.txt

Hi Song,
I agree with you. My questions and comments with [WN] in https://mailarchive.ietf.org/arch/msg/seat/MfxWpRtlTqPElX8vX4v8uiN65TU/ were also not addressed in draft-ietf-seat-use-cases-01.txt. What is meant by "peer's identity"? And how is this identity assigned to workload in confidential computing threat model?

[IM] Because your comments and questions with [WN] in <link above> do not relate to the changes made for draft-seat-use-cases-01.txt. In addition, “peer’s identity” was already used in the introduction of -00; it was not introduced by the new Attacker Model. The Attacker Model addresses association of an existing authenticated identity or key with a Target Environment, but does not define how a confidential workload obtains an identity credential. A clarification of the meaning and scope of “peer’s identity” will be provided in an upcoming revision.

Thanks,
Waqas

On Wed, Sep 16, 2026 at 3:22 AM Song Haowen <[e-mail]<mailto:[e-mail]>> wrote:
Dear Ionut,

Can you clarify why my text [1] was not included in the draft? I do not use Github.

Best,
Haowen Song

[1] https://mailarchive.ietf.org/arch/msg/seat/UsIj6o7wf4hX_uCL51TCTv-wFxU/

Ionut Mihalcea <[e-mail]<mailto:[e-mail]>> 于2026年9月15日周二 22:21写道：
Hello all,

A new version of the use-cases draft has been published, adding the recently discussed attacker model. For updates to that section, please create new PRs or new issues in Github [1].

As proposed previously [2], I plan to create a new PR to move the use-cases section to a templated model. When that is available I will provide a summary for the mailing list.

Thank you,
Ionut

[1] https://github.com/ietf-wg-seat/draft-ietf-seat-use-cases
[2] https://mailarchive.ietf.org/arch/msg/seat/5iQlAOciB2deQ6FukrLwoeX7zvk/

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 15 September 2026 at 14:53
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [Seat] I-D Action: draft-ietf-seat-use-cases-01.txt

Internet-Draft draft-ietf-seat-use-cases-01.txt is now available. It is a work
item of the Secure Evidence and Attestation Transport (SEAT) WG of the IETF.

   Title:   Security Goals and Use Cases for Integrating Remote Attestation with Secure Channel Protocols
   Author:  Ionuț Mihalcea
   Name:    draft-ietf-seat-use-cases-01.txt
   Pages:   23
   Dates:   2026-09-15

Abstract:

   This document outlines desirable security goals and use cases for
   integrating remote attestation (RA) capabilities with secure channel
   establishment protocols (e.g., TLS and DTLS).  Peer authentication in
   such protocols establishes trust in a peer's network identifiers but
   provides no assurance regarding the integrity of its underlying
   software and hardware stack.  Remote attestation addresses this gap
   by enabling a peer to provide verifiable evidence about the current
   state of the Target Environment.  This document specifies a set of
   essential security goals the protocol solution must have, including
   cryptographic binding to the secure connection, evidence freshness,
   and flexibility to support different attestation models.  It then
   explores relevant use cases, such as confidential data collaboration
   and secure secrets provisioning, to motivate the need for this
   integration.  This document is intended to serve as an input to the
   design of protocol solutions within the SEAT working group.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-seat-use-cases/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-seat-use-cases-01.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-seat-use-cases-01

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
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]>