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

["Smith, Ned" <[e-mail]>]

Here are a some of the privacy preserving approaches currently in flight in the RATS WG:

draft-ietf-rats-daa-04 - Direct Anonymous Attestation for the Remote Attestation Procedures Architecture<https://datatracker.ietf.org/doc/draft-ietf-rats-daa/> – The daa draft defines use of group signatures that allows an Attester to present Evidence anonymously, independent of the Verifier.

draft-ietf-rats-ar4si-05 - Attestation Results for Secure Interactions<https://datatracker.ietf.org/doc/draft-ietf-rats-ar4si/> – The ar4si draft describes attestation results that are a summarization of Evidence details that may be used to hide information from downstream Relying Parties.

The Attester can employ privacy preserving behavior independent of the Relying party. For example, in the passport model (RFC9334), the Attester receives the attestation result (aka passport) from the Verifier. If it contains privacy sensitive content, the Attester can refuse to supply the passport to a Relying Party.

As Laurence observed, protocol definition outside of the RATS WG also can help address privacy considerations.

-Ned

From: RATS <[e-mail]> on behalf of "lgl island-resort.com" <[e-mail]>
Date: Monday, October 9, 2023 at 12:06 PM
To: Tom Jones <[e-mail]>
Cc: "Smith, Ned" <[e-mail]>, Tom Jones <[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

EAT defines an attestation token, a signed set of claims about the device, not a round-trip protocol. Its use is usually by embedding the token in another protocol. So you know the use case from the context of the carrying protocol.

FIDO is a great example. It is clearly focused on the authentication use case. FIDO certification also defines two types, one for the open market that is privacy preserving and one for the enterprise which is not (because enterprises want it that way).

Lots of apps on mobile devices define their own protocols (i.e. JSON/REST APIs) and may or may not include attestation. Android attestation (proprietary) has been an option for some time. For example a banking app may include attestation (and you already agreed to no privacy in a banking app because banking regulations require tracking).

Privacy preservation can also be through a proxy or intermediary. The attestation goes to a neutral third party that verifies attestations but doesn’t track. The end consumer of the attestation just gets a yeah/nay, no PII.

There is tons of room in the RATS architecture for privacy preservation.

LL




On Oct 9, 2023, at 11:17 AM, Tom Jones <[e-mail]> wrote:

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