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

[tirumal reddy <[e-mail]>]

Hi,

I don't think the proposed text adds anything new to the -01 use-cases
draft.

The cited external references, CVEs, and publications are outside the scope
of the SEAT WG's active specification work, as the chairs have clarified.

More importantly, the proposed text prescribes specific mechanisms, such as
requiring shared secrets, rather than stating security requirements. The
-01 draft already covers the relevant security requirements while leaving
the solution to the protocol drafts.

I therefore don't see a need to add the proposed text to the use-cases
document.

-Tiru

On Mon, 21 Sept 2026 at 01:31, Song Haowen <[e-mail]> wrote:

> Dear all,
>
> I have revised the guidance text for ietf-seat-use-cases document based on
> working group discussion. Ionut may decide not to use it but present a
> narrow reason.
>
> Evidence MUST be bound to the secure channel. Failure to do so results in
> relay attacks [1-3].
> Verifier MUST have access to legitimate hardware identifiers of the
> Attester. Failure to do so results in relay attacks [4].
> Verifier MUST check the binding with extreme care. Failure to do so
> results in relay attacks [5,6,12-15].
> Binder MUST contain shared secrets. Failure to do so results in relay
> attacks [7-11,16,17].
>
> 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
> [12] https://www.cve.org/CVERecord?id=CVE-2026-92701
> [13] https://www.cve.org/CVERecord?id=CVE-2026-92702
> [14] https://euvd.enisa.europa.eu/enisa/EUVD-2026-83192
> [15] https://euvd.enisa.europa.eu/enisa/EUVD-2026-83194
> [16] https://www.usenix.org/system/files/atc25-weinhold.pdf
> [17]
> https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS
>
> <[e-mail]> 于2026年9月13日周日 03:31写道：
>
>> Hello,
>>
>> comments with [WN]
>>
>> On Sat, Sep 12, 2026 at 8:52 PM Nathanael Ritz <[e-mail]>
>> wrote:
>>
>> Hi, comments below with [NR]:
>>
>> On Sat, Sep 12, 2026 at 12:42 PM <[e-mail]> wrote:
>>
>>> My message landed completely on the list.
>>>
>>
>> [NR]: Can you rephrase this for me please?
>>
>> Yes, sure. IETF SEAT WG has online archive where all messages can be
>> seen. My *complete *message is available at
>> https://mailarchive.ietf.org/arch/msg/seat/MfxWpRtlTqPElX8vX4v8uiN65TU/.
>> I had *inline *comments with [WN]. I thought they were missed. I am
>> interested in other answers. I am not interested in proverif. I tried
>> proverif. But it took more time than benefit. I do not have formal
>> verification background. But now our customers demand it.
>>
>> Thanks,
>> Waqas
>>
>>
>> But the response was to only one point. That response is also very
>>> unsatisfying. Iman Schrock literally says "misunderstood" in his very first
>>> sentence in
>>> https://mailarchive.ietf.org/arch/msg/seat/rK1nDSewAbVL_weOp98knYZcg6s/.
>>> There appears to be only one person in discussion with him on his email.
>>>
>>
>> [NR]: Indeed it is difficult to tell what prompted the Iman’s
>> follow-up—given the only person I spoke to about the results was Usama; who
>> I assume hasn’t had time to read through all the emails to engage directly
>> with the narrow results and their implications yet.
>>
>> So I think it's very clear whose misunderstanding it is.
>>>
>>
>> [NR]: I think we may agree on the premise and disagree on the whom.
>>
>> Cheers,
>> Nathanael
>>
>>
>>>
>>> Thanks,
>>> Waqas
>>>
>>> On Thu, Sep 10, 2026 at 2:14 PM Nathanael Ritz <[e-mail]>
>>> wrote:
>>>
>>> On Thu, Sep 10, 2026 at 2:13 AM <[e-mail]> wrote:
>>>
>>>> [snip]
>>>>
>>>
>>>  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/
>>>
>>>
>>> [WN] I saw later in the thread your misunderstanding was corrected:
>>> https://mailarchive.ietf.org/arch/msg/seat/rK1nDSewAbVL_weOp98knYZcg6s/.
>>>
>>> [NR]: Who’s misunderstanding? From the above link:
>>>
>>> On Sun, Aug 23, 2026 at 9:48 AM Iman Schrock <[e-mail]>
>>> wrote:
>>>
>>> All,
>>>
>>> I think my earlier email was misunderstood, so let me state the narrow
>>> result clearly:
>>>
>>> - Under Nathanael’s query restrictions, the WeakDH and WeakHash paths
>>> are excluded, and binder6 still fails G1 through G3.
>>> - Binder3 passes G1 through G3 but fails the stronger secrecy and
>>> injective-agreement queries. G1 through G3 are therefore not
>>> sufficient.
>>> - Nothing in this result answers Usama’s evidence-binding concern. It
>>> remains directly relevant to SEAT.
>>> - It also makes concrete Songbo’s distinction between the baseline
>>> equality goals and the stronger security goals.
>>>
>>> This matters to SEAT because the working group should be explicit
>>> about which properties each design is expected to provide. Sophie
>>> Schmieg’s earlier note points in the same direction: the binding
>>> construction itself should be specified and analyzed, particularly
>>> whether it is derived from the shared secret.
>>>
>>> My reproduction addressed Nathanael’s published query over the pinned
>>> binder3, binder6, and proposal models. It was not the separate -04/-06
>>> experiment and neither confirms nor contradicts Usama’s analysis
>>> there. The BadElement variant likewise remains a separate experiment.
>>>
>>> Best,
>>> Iman
>>>
>>> [NR2]: Iman made it clear—without correcting anyone’s
>>> “misunderstanding”—that the experiment evaluated G1,G2,G3 and did not
>>> reflect results for draft-early-06 because the ESORICS artifacts did not
>>> and do not model draft-early-06.
>>>
>>> Cheers,
>>> Nathanael
>>>
>>>
>>>>
>>>
>>>>
>>>
>> _______________________________________________
>> 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]
>