Re: [Rats] IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet

["lgl island-resort.com" <[e-mail]>]

Hi Tom,

On Oct 9, 2023, at 2:56 PM, Tom Jones <[e-mail]<mailto:[e-mail]>> wrote:

I have trouble with much of what NED said.

All of the attestation I have seen comes with machine ID.

That’s not true. A machine ID is not required in RATS, EAT or FIDO attestation.

(s/w id, whatever) And I understand that, nothing can be said about something without some sort of ID/binding for that something.

That’s not true.  You can attest a device is a member of a class of devices using DAA and other techniques. You can also attest things about the state of the device without an machine ID.

I strongly object to any machine that can be tracked to me (even IOT can) responding to any request for any data without my explicit consent. Any collection of attributes that can be followed can become a way to track me.  I have had this particular problem with smartphones walking around in supermarkets. While this problem is not unique to attestation, it really starts with attestation. so  NO ATTESTATION REQUEST FROM ANY site that is not known to me. Would be a real privacy assertion.

There’s definitely a trade-off here. For some use cases, attestation will be able to provide security value without compromising privacy. FIDO is an example. For some use cases attestation may come at too high a cost in privacy and it is fine to not use attestation. Other cases aren’t privacy sensitive.

BTW - my bona fides - I was part of the team at Intel that created the first security co-processor in mid 1990's. I was part of some of the teams at MSFT that struggled with both versions of the TPM.

Please remember the huge outcry when Intel attempted to put an ID in a processor.

The attempt to push this off to a "DISINTERESTED" third party without a funding plan is a non-starter. (SEP field) and I never understood how this attestation could be linked to data later sent from the device anyway.

We’re not defining a single end-end attestation solution for a large number of use cases. We’re defining framework and formats for people to build attestation out of. There’s precedent for this as COSE/JOSE are not end-end encryption/signing, but rather framework and formats for privacy and authenticity that are made use of by other protocols. Similarly CWT/JWT are framework and formats for authentication (and now attestation).

So, yes there is an SEP field here, but that’s OK. COSE, JOSE, JWT, CWT have an SEP field too.

LL



..tom


On Mon, Oct 9, 2023 at 12:55 PM Smith, Ned <[e-mail]<mailto:[e-mail]>> wrote:
> There is an architectural document. There appears to be no consideration for human privacy

RFC 9334 does call out privacy considerations relating to humans. It specifically suggests removal of PII from Evidence.
“Another approach to deal with Evidence is to remove PII from the
   Evidence while still being able to verify that the Attester is one of
   a large set.  This approach is often called "Direct Anonymous
   Attestation".  See Section 6.2 of [CCC-DeepDive] and [RATS-DAA] for
   more discussion.”

User privacy threats are often concerned with user tracking and targeting. PI and PII are attributes that allow such activity.
The various drafts that define specific attributes such as draft-ietf-rats-eat-21 - The Entity Attestation Token (EAT)<https://datatracker.ietf.org/doc/draft-ietf-rats-eat/> define attributes that are optional to include in Evidence. Many are attributes that represent a class of device that in most circumstances is ineffective as PII.

The use (or not) of an attribute due to its privacy sensitivity (or not) is a policy decision. The Attester can have privacy policy that dictates which attributes are privacy sensitive. The Attester, as part of reasonable protocol design, can select which Verifier to trust to enforce the Attester’s privacy policy (in addition to locally applied policy).

Attestation that focuses on machine attributes rather than user attributes helps protect personal privacy in that it shifts the focus from humans to machines (of which there can be a large class that are the same). This approach allows user identities and credentials to be omitted while still allowing assessments that can detect malware and compromise.

Cheers,
Ned

From: RATS <[e-mail]<mailto:[e-mail]>> on behalf of Tom Jones <[e-mail]<mailto:[e-mail]>>
Date: Monday, October 9, 2023 at 12:32 PM
To: "Smith, Ned" <[e-mail]<mailto:[e-mail]>>
Cc: Tom Jones <[e-mail]<mailto:[e-mail]>>, "lgl island-resort.com<http://island-resort.com/>" <[e-mail]<mailto:[e-mail]>>, Michael Richardson <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, rats <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet

To be clear. There is an architectural document. There appears to be no consideration for human privacy. Can this gap be addressed within this community. Or is there a sep field in operation here. (See someone else's problem, hitch hiker's guide )
thx ..Tom (mobile)

On Mon, Oct 9, 2023, 11:27 AM Smith, Ned <[e-mail]<mailto:[e-mail]>> wrote:
> so then, there is no hope for privacy preserving architecture from RATS?

Does “RATS” refer to the WG or RFC9334? And I didn’t say privacy preserving attestation was hopeless.

From: Tom Jones <[e-mail]<mailto:[e-mail]>>
Date: Monday, October 9, 2023 at 11:17 AM
To: "Smith, Ned" <[e-mail]<mailto:[e-mail]>>, Tom Jones <[e-mail]<mailto:[e-mail]>>, "lgl island-resort.com<http://island-resort.com/>" <[e-mail]<mailto:[e-mail]>>
Cc: Michael Richardson <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, rats <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet

so then, there is no hope for privacy preserving architecture from RATS?

Peace ..tom
________________________________
From: Smith, Ned <[e-mail]<mailto:[e-mail]>>
Sent: Monday, October 9, 2023 11:13 AM
To: Tom Jones <[e-mail]<mailto:[e-mail]>>; lgl island-resort.com<http://island-resort.com/> <[e-mail]<mailto:[e-mail]>>
Cc: Michael Richardson <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; rats <[e-mail]<mailto:[e-mail]>>; Tom Jones <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet


> The problem then is that the verifier must state what the use case is in a trustworthy message.

If there is a gap in the RATS Architecture, it is that it didn’t acknowledge the need for a Verifier to present usage/context to the Attester as a prerequisite to disclosing Evidence. And it assumes the relying party doesn’t need to present usage/context to the Verifier before disclosing Attestation Results.



In its defense, the RATS Architecture wasn’t trying to define a protocol, rather a conceptual flow of information. Actual protocols would consider deployment and usage context and address privacy considerations as appropriate. Consider an embedded system behind a firewall, this may not need the deployment context to be communicated in a protocol message since the context is embedded.



-Ned



From: RATS <[e-mail]<mailto:[e-mail]>> on behalf of Tom Jones <[e-mail]<mailto:[e-mail]>>
Date: Sunday, October 8, 2023 at 11:12 PM
To: "lgl island-resort.com<http://island-resort.com/>" <[e-mail]<mailto:[e-mail]>>
Cc: Michael Richardson <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, rats <[e-mail]<mailto:[e-mail]>>, Tom Jones <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet



The problem then is that the verifier must state what the use case is in a trustworthy message.

thx ..Tom (mobile)



On Sun, Oct 8, 2023, 11:41 AM lgl island-resort.com<http://island-resort.com/> <[e-mail]<mailto:[e-mail]>> wrote:

I think the workable strategy is privacy-preserving attestation. The attestation target (e.g. client device) reveals only enough to prove the security characteristics that it needs to for the use case. FIDO supports this sort of thing.



In some ways, formal, cryptographically secured attestation doesn’t change things. Web sites already try to collect as much personal information as possible. The OS and the web browser defend.



The IAB’s comment, is that web sites and services would deny service unless the client device provided attestation of their SW stack and such. That’s different than the privacy issue.



LL







On Oct 7, 2023, at 11:03 PM, Tom Jones <[e-mail]<mailto:[e-mail]>> wrote:



Granted that the iab doc is difficult, I would like to state an objection in terms of the user.



No verifier may ever request more attestation than they are willing to first provide.



What's sauce for the goose is sauce for the gander.



That would limit the sites that just troll users to see what they can discover to the sites that the user is willing to trust.



Generally I agree with panwei.

thx ..Tom (mobile)



On Mon, Oct 2, 2023, 7:16 PM Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:

IAB Executive Administrative Manager <[e-mail]<mailto:[e-mail]>> wrote:
    > On 25 September 2023, the Internet Architecture Board (IAB) posted a
    > new IAB Statement on the Risks of Attestation of Software and Hardware
    > on the Open Internet[1].

    > [1]
    > https://datatracker.ietf.org/doc/statement-iab-statement-on-the-risks-of-attestation-of-software-and-hardware-on-the-open-internet/

It's an interesting statement, and I suspect that I agree with the intent.
As written, it fails to inform: you need to know what the treacherous uses of
remote attestation are (and then take two steps not detailed in this
statement) in order to understand the statement.
I think that this should be revised, and it shouldn't be so timid.

As an author of RFC9334, I'm rather surprised that this statement was issued
without any consultation with us.

As written, I find this statement useless.
I would be happy to work with the IAB to craft a better statement.

--
Michael Richardson <[e-mail]<mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




_______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats

_______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats