[Seat] Re: New Version Notification for draft-mihalcea-seat-use-cases-02.txt

[Nathanael Ritz <[e-mail]>]

Hello,

On Sat, May 9, 2026 at 3:55 PM Muhammad Usama Sardar <
[e-mail]> wrote:
> Please review [9] and constructively propose any changes.

I appreciate the repeated invitation to review [9] although you may
appreciate that by calling it a "cute little PR", I took the phrasing to
suggest the urgency required for an immediate closer look was somewhat
constrained. However I will be sure to review it and offer feedback to the
WG when I can.

On Sat, May 9, 2026 at 3:55 PM Muhammad Usama Sardar <
[e-mail]> wrote:
> Does someone see any “mechanisms for key leakage” in Table 1 in [8]? I
don’t. This seems like misinterpretation of Table 1.
Yup, got my wires crossed a bit with my phrasing. The mechanisms are
discussed in Sec. 4.2.1. Thanks for the correction.

Regarding #43, I want to be clear: PKI binding with Remote Attestation is
well-motivated and the ID-Crisis paper establishes that much clearly.

Binding Evidence to an infrastructure-supplied or hardware-associated
identifier provides strong compound authentication when such an identifier
is available and verifiable. In deployments where those identifiers are
unavailable or unverifiable, alternative identifiers can still be
meaningful. While they do not provide the same semantics as a verifiable
physical machine identifier, they can still provide protection against
single key promise.

That said, if the relevant hardware root of trust is compromised, or if
signing material is extracted by a physical attack, then the identifiers
covered by that compromised material no longer guarantee the physical
hardware association they once did.

So yes, machine/platform identity binding is valuable. But the proposed
Section 3.3 text should not frame the absence of infrastructure-supplied
hardware identity as the cause of the physical attacks cited, and it should
not imply that a Layer 7 protocol property prevents those Layer 1 attacks
themselves.

Cheers,

Nathanael

On Sat, 9 May 2026 at 15:55, Muhammad Usama Sardar <
[e-mail]> wrote:

> Hi all,
>
> My opinion remains unchanged. With the two proposed PRs, I believe all
> comments in this thread have been addressed modulo some wordsmithing.
>
> If someone disagrees, please *constructively* propose edits directly in
> the PR and if the edits are substantial, please bring to list for
> consideration by authors and WG.
>
>
> 2 key points:
>
>    1. Outside the scope of TDX/SEV-SNP threat model simply means that
>    Intel and AMD don't account for it. That makes attacker's job much easier,
>    i.e., that doesn't stop exploit in the real world.
>    2. The paper under discussion [8] has been presented at several IETF
>    meetings. If someone has missed, please see recordings [10]. If possible,
>    please also consider to read [8] completely before any further follow-up.
>    To respect the mail list procedures, I'll respond only when something new
>    is brought on the table.
>
>
> On 09.05.26 21:35, Nathanael Ritz wrote:
>
> My concern is that the proposed text conflates what a Layer 7 protocol
> could possibly accomplish in the face of a Layer 1 physical attack such as
> those mentioned in the proposed text. If an attacker exfiltrates the
> silicon's root private key, the trust anchor is gone, meaning every piece
> of data it signs, including its own physical identity, can be spoofed in
> software.
>
> Not to put too fine a point on it, my question is simply: key of *which*
> server is exfiltrated? Do we want that exfiltrating key of one server can
> potentially break down any connection anywhere in the world?
>
> Please see Sec. 8.1 of [8] for technical details.
>
> Further, the ID-Crisis threat model (Table 1) explicitly scopes to
> transient execution attacks, side-channel attacks, and implementation
> errors as the mechanisms for key leakage.
>
> Does someone see any "mechanisms for key leakage" in Table 1 in [8]? I
> don't. This seems like misinterpretation of Table 1.
>
> Please note that even the text in Sec. 4.2.1 [8] absolutely does *not*
> exclude anything. It says it *can* happen due to three *main* categories.
>
> More precisely, the disclosed diversion attacks in Sections 8.1 and 8.2
> are Dolev-Yao network-layer attacks that exploit the absence of PKI
> identity binding [8], not physical hardware compromise.
>
> Please see comments above.
>
> I am fine if the suggested changes I proposed to the same PR are moved
> elsewhere (such as to [9]),
>
> Please review [9] and *constructively* propose any changes.
>
> but I do not believe that the use-cases document for a Layer 7 protocol
> should include properties that implies capablities for mitigation against
> Layer 1 physical attacks that hardware vendors themselves place outside
> their threat models [*].
>
> Please understand that the vendors not considering physical attacks is
> exactly the reason why this property is required.
>
> Sincerely,
>
> -Usama
>
> [0]
> https://github.com/tls-attestation/use-cases-and-properties/blob/b50619cb3a6a71f1318c58a899380e038b21ff12/draft-mihalcea-seat-use-cases.md
> [1]
> https://github.com/tls-attestation/use-cases-and-properties/pull/43/commits/b50619cb3a6a71f1318c58a899380e038b21ff12#r3212889712
> [2] https://tee.fail
> [3] https://wiretap.fail
> [4]
> https://www.intel.com/content/www/us/en/security-center/announcement/intel-security-announcement-2025-10-28-001.html
> [5]
> https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3040.html
> [6] https://badram.eu
> [7]
> https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3015.html
> [8]
> https://www.researchgate.net/publication/398839141_Identity_Crisis_in_Confidential_Computing_Formal_Analysis_of_Attested_TLS
> [9] https://github.com/tls-attestation/use-cases-and-properties/pull/44
>
> [10]
> https://github.com/CCC-Attestation/formal-spec-id-crisis#upcoming-and-recent-talks-and-research-visits
> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>