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

[Songbo Bu <[e-mail]>]

Hi Ionut, Haowen, Waqas, Chengxin, all,

Thank you.

Ionut, where we would be if the debate is settled? Separation of remote
attestation from code is not correct; you have to do re-attestation anyway.

CSA's article [1] also settled the debate by clearly stating:

"What happens if the eBPF layer feeding your AI has been compromised?

That is the question we asked ourselves after years of working on kernel
security for federal and commercial systems. What we found, and what the
industry still had not accounted for, is that eBPF opens a privileged
attack surface where runtime memory tampering goes completely unmonitored.
Worse, the data coming out of a compromised kernel space is being fed
directly into AI systems making enforcement decisions at scale.

This is no longer only our observation. In July 2026, MITRE released a
Framework for public review, developed with founding collaborators
Fr0ntierX and Invary, that formalizes exactly this problem."

See also:

"An attacker with root access, a kernel-level exploit, or a misused
privileged container can modify eBPF programs after verification. We have
seen techniques that involve swapping map pointers, redirecting function
hooks, or injecting modified bytecode directly into memory. From a logging
and monitoring standpoint, everything looks clean, but the actual
functionality  underneath has been hijacked. In that moment, your AI is not
just blind. It is being misled."

Best,
Songbo

[1]
https://cloudsecurityalliance.org/blog/2026/09/09/mitre-s-new-framework-securing-the-ebpf-layer-your-ai-depends-on

Chengxin Huang <[e-mail]> 于2026年9月19日周六 12:25写道：

> 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.
>
> 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.
>
> 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]>
> wrote:
>
>> Below with [IM]
>>
>> *From: *[e-mail] <[e-mail]>
>> *Date: *Thursday, 17 September 2026 at 20:54
>> *To: *[e-mail] <[e-mail]>
>> *Cc: *Ionut Mihalcea <[e-mail]>; [e-mail] <
>> [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]>
>> 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]> 于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] <[e-mail]>
>> *Date: *Tuesday, 15 September 2026 at 14:53
>> *To: *[e-mail] <[e-mail]>
>> *Cc: *[e-mail] <[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]
>> To unsubscribe send an email to [e-mail]
>> _______________________________________________
>> Seat mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>>
>> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>