[Seat] Re: Guidance text for draft-ietf-seat-use-cases

[Nathanael Ritz <[e-mail]>]

Hi, see below with [NR]:

On Wed, 9 Sept 2026 at 19:56, Steve <[e-mail]> wrote:

> If binding to handshake secrets alone were sufficient, the TLS WG would
> have defined standard exporter directly from those secrets. The fact that
> it has not done so should already make us cautious about claiming that such
> binding is "certainly" sufficient, even within the conventional TLS threat
> model.
>
> For Attested TLS, the situation is even more strict with the server itself
> as untrusted. It is therefore even less justified to claim that binding to
> handshake secrets is "certainly" sufficient in that setting. For this
> reason, I remain strongly opposed to making such "certainly" statements for
> Attested TLS which do not hold even for TLS itself.
>

[NR]: The so-called "standard exporter" was introduced with RFC 8446 in
August of 2018. RATS appears to have been charted in May of 2019, so the
argument is a bit of an anachronism, I think, considering technology has
developed significantly over the past decade. Now, thanks in large part to
the RATS WG, we have more standards-based access to HW-backed RoTs that
make the concept proposed by aTLS much more practical than it would have
been in 2018.

 On Wed, 9 Sept 2026 at 19:56, Steve <[e-mail]> wrote:

> I also do not understand why scientific papers that have been reviewed at
> three top conferences (USENIX ATC, ASIA CCS, and ESORICS) are repeatedly
> characterized as "promotional" by specific individual, particularly when
> these papers focus exclusively on Attested TLS and are directly within the
> scope of the charter. The artifacts from ASIA CCS and ESORICS have provided
> a solid foundation for our work. I have learned a lot from these artifacts.
>
> If Sardar et al.'s artifacts are considered "promotional", then why would
> Dr. Ritz's individual, personal, non-peer-reviewed artifacts not be
> considered "promotional"? If Sardar et al.'s artifacts are considered "out
> of scope", then why would Nathanael's artifacts not similarly be considered
> "out of scope"? The same standard should be applied consistently and
> fairly. What are "external papers"? Are there any internal papers? IETF
> does not publish any papers. So I see these phrases only as a distraction.
> Would every evidence showing that early attestation is vulnerable be
> dismissed as "promotional", "out of scope" or "external"?
>

[NR]: The chairs have already closed this topic:
https://mailarchive.ietf.org/arch/msg/seat/urMdvob5rE_4kmk9vx16NThqOhk/

 On Wed, 9 Sept 2026 at 19:56, Steve <[e-mail]> wrote:

> To be frank, repeatedly treating papers' results this way only makes me
> increasingly skeptical of early attestation. If there is a technical
> objection to these papers or artifacts, I would encourage making that
> technical argument explicitly such that the working group can discuss it.
> Sardar et al. have also explicitly welcomed critique, both on the mailing
> list and in their repository. Let us therefore keep the discussion
> technically focused.
>

[NR]: Given the above, I believe the appropriate place for disagreements
with Sardar et al.'s published papers and artifacts would be within his own
repositories, instead of relitigating them over and over on this list.

 On Wed, 9 Sept 2026 at 19:56, Steve <[e-mail]> wrote:

> Abstracting HKDF-Expand-Label functions, simply substituting "pubEK ||
> log_SH" for "rdata" in Sardar's artifacts gives the results for binding
> strengths of draft-fossati-seat-early-attestation-06 [early-binder]. I also
> tried it with HKDF-Expand-Label by faithfully representing the binder
> [early-binder] and it also gives same results as Sardar et al. have.
> Therefore, the constructive way forward would be to identify precisely what
> is missing or different from those artifacts.
>

[NR]: Iman Schrock already provided an independent analysis of Usama's
G1,G2,G3 binder strengths under standard cryptographic assumptions for TLS
1.3 here:
https://mailarchive.ietf.org/arch/msg/seat/JWKMYY1YG1E2iS_HyQ4rDmOsDGw/

On Wed, 9 Sept 2026 at 19:56, Steve <[e-mail]> wrote:

> Would it be possible for Dr. Ritz to make a fork and demonstrate the
> difference? Similar requests to show the difference have also been made
> previously. I think this would be the most useful way to move the
> discussion forward. I am genuinely interested in seeing what has been
> changed in the artifacts I reviewed that leads to such substantially
> different results.
>

[NR]: The full source for the recent models I brought forward, paired with
their full results, are available directly from the Editor's Copy for the
individual Internet-Draft for SEAT Architecture here:
https://github.com/tls-attestation/seat-architecture/tree/main/symbolic-models/aTLS
and
anyone is welcome to download them and use their own tools to compare it
with any of Sardar et al.'s published work. Feedback is welcome as a PR or
technical discussion related to SEAT proposals are welcome in the original
thread [0].

Cheers,
Nathanael

[0] https://mailarchive.ietf.org/arch/msg/seat/upV8i1kPT-3jHTAYkUOjUA92sZE/


> [snip]
> Best regards,
>
> Steve Luo
>
> Research Analyst, Cloud Security Alliance (CSA-GCR)
>
> [early-binder]
> https://www.ietf.org/archive/id/draft-fossati-seat-early-attestation-06.html#section-5.1.1
> [missing-property]
> https://mailarchive.ietf.org/arch/msg/seat/3oHcKPtXLfBUYCZoN1nnO6e1F-s/
> [CSA]
> https://cloudsecurityalliance.org/blog/2026/09/09/mitre-s-new-framework-securing-the-ebpf-layer-your-ai-depends-on
> [ca]
> https://www.mitre.org/news-insights/publication/framework-continuous-remote-attestation
>
> Mark Novak <[e-mail]> 于2026年9月8日周二 05:47写道：
>
>> I agree that credential acquisition is out of scope for SEAT as it is for
>> WIMSE. We are working this out in RATS and in the TWI SIG at the CCC, and
>> there is some work on attested CSR in LAMPS.
>> ------------------------------
>> *From:* Songbo Bu <[e-mail]>
>> *Sent:* Monday, September 7, 2026 8:09 AM
>> *To:* Ionut Mihalcea <[e-mail]>
>> *Cc:* [e-mail] <[e-mail]>; nd <[e-mail]>
>> *Subject:* [Seat] Re: Guidance text for draft-ietf-seat-use-cases
>>
>> All,
>>
>> This is a response to Dr. Ritz but not directly.
>>
>> Many substantive narrow technical questions remain unaddressed, most
>> notably: how does the attester obtain the identity for confidential
>> computing [1]?
>>
>> “Confidential workloads” are explicitly within the scope of SEAT charter.
>> It is incorrect to frame it as “out-of-scope”. Our deployment relies on
>> confidential computing. Framing this aspect as “out-of-scope” does not
>> address the practical requirements of our implementation.
>>
>> Best, Songbo
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/seat/9f-21JMK6s1Pdcob6mPo06rNwmQ/
>>
>> Ionut Mihalcea <[e-mail]> 于2026年9月7日周一 17:31写道：
>>
>> Hi,
>>
>> Below with [IM].
>>
>> *From: *Song Haowen <[e-mail]>
>> *Date: *Sunday, 6 September 2026 at 05:09
>> *To: *Ionut Mihalcea <[e-mail]>; [e-mail] <
>> [e-mail]>
>> *Subject: *Re: [Seat] Guidance text for draft-ietf-seat-use-cases
>>
>> Dear Ionut,
>>
>> "Carefully" is also used in RFC 9846. It also uses "extreme care" and
>> "additional care". Can you explain the technical problem in using it?
>>
>> [IM] Of course. The normative use of "MUST" is a binding requirement from
>> a specification. As such, the sentence has to be perfectly clear about what
>> an implementer or user has to do, how to do it, when to do it...
>> "carefully", "with extreme care", "with additional care" provide no such
>> objective understanding. "MUST verify" is already as strong of a
>> requirement as there can be.
>>
>> > "Our work so far has indicated that shared secrets are not required as
>> part of the binder to prevent relay attacks."
>>
>> I have read your work [13]. In my understanding, Section 5 of your work
>> reaches the same conclusion that Usama, Viacheslav and Jean have formally
>> reached. In Section 5 of your work, you write:
>>
>> "As the key difference compared to the transcript hash, this linking hash
>> is computed over the same TLS handshake messages, but also includes the
>> DHEderived shared secret. Without this shared secret, the linking hash
>> would only cover publicly visible information of handshake messages,
>> therefore opening the possibility of a relay attack. Including the shared
>> secret, which is only known to the connecting parties, prevents this
>> attack. The verifying peer can compute the same hash, because it actively
>> participated in the DHE key exchange."
>>
>> So based on your own work, shared secrets in binder is also tables stake
>> for SEAT.
>>
>> [IM] Alas, draft-fossati-seat-early-attestation is a more up-to-date
>> version of my work, so you can be assured that I meant it the first time
>> around.
>>
>> > "I notice you included [5] and [6] for some reason, without quoting
>> them, probably because of [12]."
>>
>> No, I wanted to have [5-6] for my third requirement.
>>
>> Best,
>> Haowen Song
>>
>> [1]
>> https://github.com/ultravioletrs/cocos/security/advisories/GHSA-vfgg-mvxx-mgg7
>> [2] https://www.cve.org/CVERecord?id=CVE-2026-33697
>> [3] https://euvd.enisa.europa.eu/enisa/EUVD-2026-16488
>> [4]
>> https://github.com/edgelesssys/contrast/security/advisories/GHSA-hjgc-jc5v-fw7h
>> [5]
>> https://github.com/ultravioletrs/cocos/security/advisories/GHSA-4px3-wj2x-xx47
>> [6]
>> https://github.com/ultravioletrs/cocos/security/advisories/GHSA-4r6g-mp48-j2rw
>> [7]
>> https://github.com/Privasys/enclave-os-mini/security/advisories/GHSA-49qm-4pj3-w2c6
>> [8]
>> https://github.com/Privasys/enclave-os-virtual/security/advisories/GHSA-p5fp-g94g-g9m9
>> [9]
>> https://github.com/Privasys/go/security/advisories/GHSA-7jfw-53rm-phh2
>> [10]
>> https://github.com/Privasys/ra-tls-clients/security/advisories/GHSA-5qrc-v874-mxvx
>> [11]
>> https://github.com/Privasys/rustls/security/advisories/GHSA-j6qv-435v-r492
>> [13] https://www.usenix.org/system/files/atc25-weinhold.pdf
>>
>> Ionut Mihalcea <[e-mail]> 于2026年9月5日周六 00:48写道：
>>
>> Hi,
>>
>> Thanks for the text, see inline with [IM].
>>
>> *From: *Song Haowen <[e-mail]>
>> *Date: *Friday, 4 September 2026 at 16:51
>> *To: *[e-mail] <[e-mail]>
>> *Subject: *[Seat] Guidance text for draft-ietf-seat-use-cases
>>
>> Dear all,
>>
>> I have created the following guidance text for ietf-seat-use-cases
>> document. The working group may choose not to use it. Usama, Viacheslav,
>> Jean and Songbo can correct me if I am wrong.
>>
>> Evidence MUST be bound to the secure channel. Failure to do so results in
>> relay attacks [1-3].
>>
>> [IM] This is, of course, table stakes for SEAT, since this is part of the
>> charter as well. The required invariant is encoded as part of the `Evidence
>> Relay` attack in the ongoing PR [L265].
>>
>> [L265]
>> https://github.com/ietf-wg-seat/draft-ietf-seat-use-cases/pull/59/changes#diff-58067db1669a549a0d74093d3cb66d0119aa6a47e5ffd9ced16bb2fdb3341463R265
>>
>>
>> Verifier MUST have access to legitimate hardware identifiers of the
>> Attester. Failure to do so results in relay attacks [4].
>>
>> [IM] I agree with the requirement, but since this is not something the
>> attested TLS protocol design can mitigate against, I think it would be
>> better suited for an architecture draft.
>>
>>
>> Verifier MUST carefully check the binding. Failure to do so results in
>> relay attacks [4].
>>
>> [IM] That doesn't sound like it could be a normative sentence: what does
>> "carefully" mean here? It's certainly part of the appraisal policy for
>> Verifier and/or Relying Party - not just checking the binding, but
>> computing it in the same way on both sides of the TLS connection. Also, as
>> currently written it would apply to the architecture draft, for the same
>> reason as above.
>>
>>
>> Binder MUST contain shared secrets. Failure to do so results in relay
>> attacks [7-11].
>>
>> [IM] I disagree. Your linked advisories do not prove it - they just make
>> the case that some software vendor decided to switch from one binding
>> mechanism to another. Our work so far has indicated that shared secrets are
>> not required as part of the binder to prevent relay attacks.
>>
>> [IM] Oh, also, regarding the advisories and CVEs below. I notice you
>> included [5] and [6] for some reason, without quoting them, probably
>> because of [12].
>>
>> [12] https://github.com/ultravioletrs/cocos/issues/615
>>
>> Best,
>> Haowen Song
>>
>> [1]
>> https://github.com/ultravioletrs/cocos/security/advisories/GHSA-vfgg-mvxx-mgg7
>> [2] https://www.cve.org/CVERecord?id=CVE-2026-33697
>> [3] https://euvd.enisa.europa.eu/enisa/EUVD-2026-16488
>> [4]
>> https://github.com/edgelesssys/contrast/security/advisories/GHSA-hjgc-jc5v-fw7h
>> [5]
>> https://github.com/ultravioletrs/cocos/security/advisories/GHSA-4px3-wj2x-xx47
>> [6]
>> https://github.com/ultravioletrs/cocos/security/advisories/GHSA-4r6g-mp48-j2rw
>> [7]
>> https://github.com/Privasys/enclave-os-mini/security/advisories/GHSA-49qm-4pj3-w2c6
>> [8]
>> https://github.com/Privasys/enclave-os-virtual/security/advisories/GHSA-p5fp-g94g-g9m9
>> [9]
>> https://github.com/Privasys/go/security/advisories/GHSA-7jfw-53rm-phh2
>> [10]
>> https://github.com/Privasys/ra-tls-clients/security/advisories/GHSA-5qrc-v874-mxvx
>> [11]
>> https://github.com/Privasys/rustls/security/advisories/GHSA-j6qv-435v-r492
>>
>> _______________________________________________
>> 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]
>