[Seat] Re: [Rats] [WIMSE] Re: Re: Re: Re: Follow-up of meeting 122 presentation (Formal proof of insecurity of Intel's RA-TLS and draft-fossati-tls-attestation)

[John Kemp <[e-mail]>]

Hi Nathanael,

> El ene 16, 2026, a las 4:38 p.m., Nathanael Ritz <[e-mail]> escribió:
> 
> I am not sure about WIMSE, and apologies to the WG if it appears that I am conflating SPIFFE/SPIRE for WIMSE, as that’s not my intention. With that out of the way, if we use SPIRE as an example of what’s done in industry right now, their “node attestation” process comes from a SPIRE agent running a specific plugin that is checked against a policy. Plugin choices are diverse, to address the specific question about “hardware vs software ‘attestation’”. 

Agreed.

> 
> For example, a SPIRE agent can “attest” using a Keylime (HW RoT/TPM) plugin or it can “attest” with a bootstrap bearer-token (join_token), although I believe using join_tokens are strongly advised against. In any case, if the “attestation” is accepted, the SPIRE agent on the node is handed a “verifiable identity” in the form of an SVID (X.509 cert). 
> 
> There is a separate process where the RBAC policy engine uses “selectors” to “discover” what kind of privileges the successful node can have, but that’s checked independently from the initial “node attestation” process. 
> 
> My opinion to the WG is that I am very much against using “attestation” as a noun if a node is given some static credential by passing a bearer-token.

The Attester (the agent on the node) passes the token it received from the server (by some means unspecified) as Evidence, to a Relying Party (the server) that asks a Verifier (sometimes the same entity as the Relying Party itself) to check the Evidence. If the token is one generated by the Verifier/RP, and it has not been used, then the “attestation” is approved, and the agent joins the trust domain. 

I hear you that this is very different than having some number of third-party attestations about a key used from a secure element that has the endorsement of some other trusted third-party manufacturer whose PKI I can verify, and which comes with Evidence in form of measurements about the hardware and software environment that are rooted in that PKI.

SPIRE is not the first environment to use the “join token” mechanism, and will likely not be the last. It’s also the case that I can think of relatively secure ways to implement that, and relatively insecure ways to. 

By giving the join token one-time-use semantics, I already don’t think it’s a horrible mechanism...

I do agree that precise differences between authentication and attestation are difficult, unless you narrow down what you are willing to accept from an architecture that supports many different implementations. 

> As such mechanisms conflate authentication (through possession of an unbound secret) for authorization, but TOFU is what it is, and that’s the language used with SPIFFE, regardless of plugin choice, iirc. 
> 
> The key detail is that the SPIRE plugin system allows both software or hardware mechanisms for establishing trust and it appears WIMSE aligns with similar use of language. 

Agreed. That is the key detail.

Regards, -johnk

> 
> - Nathanael 
> 
> On Fri, Jan 16, 2026 at 2:05 PM John Kemp <[e-mail] <mailto:[e-mail]>> wrote:
>>> El ene 16, 2026, a las 3:35 p.m., Muhammad Usama Sardar <[e-mail] <mailto:[e-mail]>> escribió:
>>> 
>>> Could WIMSE clarify which one of the following is intended in its attestation?
>>> 
>>> Software-based attestation only
>>> Any of software-based attestation or hardware-based attestation
>>> If it is #1, then our attacks are completely irrelevant and I'll close my PR.
>>> 
>>> So a simple question for WIMSE is: is hardware-based attestation in scope or not?
>>> 
>> At the architecture level we’re operating at (not specific implementations) I would say that whether it is hardware-based or software-based is not relevant. Either are possible and allowed. 
>>> If hardware-based attestation is in scope, attacks are in scope.
>>> 
>> As I believe has been previously noted, the attacks you are talking about are quite specific — to “attested TLS” - I can’t say whether this is the correct document since it’s an expired draft, but there is a security considerations section of https://www.ietf.org/archive/id/draft-fossati-tls-attestation-09.html#name-security-considerations in the attested TLS document that would seem the correct place for a discussion of those attacks. 
>> 
>> In the WIMSE architecture document (the subject of this discussion) we do not refer to attested TLS at all, and it would be an implementation detail at the level of this document, so I would suggest it is out-of-scope.
>>> 
>>> If hardware-based attestation is out of scope, I don't really see why definition says WIMSE attestation is broader than RFC9334. In this case, maybe simply say it is software-based attestation.
>>> 
>> Hardware-based attestation is in-scope, but the specific type, or the mechanism by which is used (being different from the seven described RATS attestation use-cases), is not relevant for the WIMSE architecture document, in my opinion.
>> 
>> Regards, -johnk
>> 
>>> 
>>> On 16.01.26 19:54, John Kemp wrote:
>>>>> WIMSE folks seem to have settled at some definition. Looking at the current definition of attestation of WIMSE in PR [1], I have proposed a small edit there.
>>>>> 
>>>>> One nit: Definition says "Attestation in WIMSE is intentionally defined quite broadly" but I don't see what exactly is broader than RFC9334.
>>>>> 
>>>> What that specifically means to me is that the WIMSE definition is broader than the defined use-cases specifically mentioned in RFC9334.
>>> Well, I don't think that is quite right. RFC9334 never "defined" any use case. Sec. 2 says "Reference Use Cases". We don't limit remote attestation to these use cases only. The start of Sec. 2 says explicitly:
>>> 
>>> This section covers a number of representative and generic use cases for remote attestation, independent of specific solutions. The purpose is to provide motivation for various aspects of the architecture presented in this document. Many other use cases exist; this document does not contain a complete list. It only illustrates a set of use cases that collectively cover all the functionality required in the architecture.
>>> 
>>> -Usama
>>