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

[Henk Birkholz <[e-mail]>]

On 09.10.23 23:56, Tom Jones wrote:
> I have trouble with much of what NED said.

Hi Tom,

to your comment:

> There is an architectural document. There appears to be no consideration for human privacy

That is correct with the exception of

> https://www.rfc-editor.org/rfc/rfc9334.html#name-privacy-considerations

Is there something explicitly missing that you would like to see in that 
section? If so, Ned highlight two documents where we can add further 
statements or we can do another round on RFC 9334, if that seems warranted.

Also, declaring the "class" of, for example, Evidence generating 
hardware/firmware and thereby something to the effect of type, model, 
version of hardware and its protected capabilities is all over the place 
in RATS documents. Two examples:

> https://www.ietf.org/archive/id/draft-ietf-rats-eat-21.html#name-hwmodel-hardware-model-clai

or

> https://www.ietf.org/archive/id/draft-ietf-rats-corim-02.html#name-class

If indicating TEE or HSM class only in remote attestation Evidence or 
corresponding Attestation Results is not enough, could you elaborate 
more on what you think is required here?

> 
> All of the attestation I have seen comes with machine ID. (s/w id, 

I have seen tons of attestations, such as SBOMs, code reviews or CVEs 
that come without a machine ID. I am a bit surprised by that assessment, 
to be honest.

> 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.

I think we have moved on a bit in the recent years, but maybe this 
thread helps to identified issues with existing IETF documents that we 
can fix!

> 
> 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.

Could you elaborate a bit more about your usage scenario here? And maybe 
provide a pointer to get more familiar with the issue?


Viele Grüße,

Henk

> 
> ..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/ <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
>                     <https://www.ietf.org/mailman/listinfo/rats>____
> 
>                 _______________________________________________
>                 RATS mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/rats
>                 <https://www.ietf.org/mailman/listinfo/rats>____
> 
>             ____
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats