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

[Tom Jones <[e-mail]>]

I have trouble with much of what NED said.

All of the attestation I have seen comes with machine ID. (s/w id,
whatever) And I understand that, nothing can be said about something
without some sort of ID/binding for that something.
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.

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.

..tom


On Mon, Oct 9, 2023 at 12:55 PM Smith, Ned <[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]> on behalf of Tom Jones <
> [e-mail]>
> *Date: *Monday, October 9, 2023 at 12:32 PM
> *To: *"Smith, Ned" <[e-mail]>
> *Cc: *Tom Jones <[e-mail]>, "lgl island-resort.com" <
> [e-mail]>, Michael Richardson <[e-mail]>, "
> [e-mail]" <[e-mail]>, rats <[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]> 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]>
> *Date: *Monday, October 9, 2023 at 11:17 AM
> *To: *"Smith, Ned" <[e-mail]>, Tom Jones <
> [e-mail]>, "lgl island-resort.com" <
> [e-mail]>
> *Cc: *Michael Richardson <[e-mail]>, "[e-mail]" <
> [e-mail]>, rats <[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]>
> *Sent:* Monday, October 9, 2023 11:13 AM
> *To:* Tom Jones <[e-mail]>; lgl island-resort.com <
> [e-mail]>
> *Cc:* Michael Richardson <[e-mail]>; [e-mail] <[e-mail]>;
> rats <[e-mail]>; Tom Jones <[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]> on behalf of Tom Jones <
> [e-mail]>
> *Date: *Sunday, October 8, 2023 at 11:12 PM
> *To: *"lgl island-resort.com" <[e-mail]>
> *Cc: *Michael Richardson <[e-mail]>, "[e-mail]" <
> [e-mail]>, rats <[e-mail]>, Tom Jones <[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 <[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]>
> 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]>
> wrote:
>
>
> IAB Executive Administrative Manager <[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]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>
>
>
>