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

[Tommy Pauly <[e-mail]>]

> On Oct 3, 2023, at 3:24 PM, Smith, Ned <[e-mail]> wrote:
> 
> +1 to comments from Michael, Dave, and Kathleen.
>  
> I have procedural concerns with the IAB statement as it seems to endorse the opinion of the Web Environment Integrity <https://github.com/RupertBenWiser/Web-Environment-Integrity> authors, which is not an official IETF document AFAIK. Consequently, it is difficult to assess whether the IAB endorsement reflects broader consensus within the IETF.

To be clear, the statement is not endorsing the Web Environment Integrity proposal; rather, it is pointing to such uses of attestation (that are designed to verify specific versions of browsers on specific platforms) are problematic. That proposal is not an IETF proposal, nor an official W3C proposal, but is proposing a direction that could cause harm to the Internet ecosystem.

Thanks,
Tommy

>  
> It is good to see a discussion thread starting that considers issues, use cases, requirements, and concerns of attestation in the broader web context, but the culture of the IETF would be to have that discussion before the IAB formalizes an opinion.
>  
> -Ned
>  
> From: RATS <[e-mail]> on behalf of Kathleen Moriarty <[e-mail]>
> Date: Tuesday, October 3, 2023 at 1:22 PM
> To: "dthaler1968=[e-mail]" <dthaler1968=[e-mail]>
> Cc: Michael Richardson <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [Rats] IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet
>  
> Greetings.
>  
> I would also be happy to work with the IAB to create a better statement. I am in agreement with Michael and Dave. The current statement reads as though some uses of attestation were conflated in ways those of us working on it would have been able to assist to provide greater clarity towards the goals of the IAB for openness.
>  
> The ability to assure the firmware and software of a system using standards and widely deployed hardware is critical to leveling the playing field for security, better serving those with fewer resources. The technology has the potential to reduce the need for external scanners, while enabling lower cost methods to implement integrity and posture assurance with standard formats and protocols. More likely, it will provide a method of assurance for those with few resources. Those with more resources might use attestation plus external scanning tools that are in use today. These checks on software or system changes also aids in the detection of lateral movement of attackers. The earlier attackers can be detected, the better for those impacted. Attestation provides a standards based method to implement this integrity checking to meet zero trust requirements.
>  
> Thank you for considering these comments and the offer to assist.
>  
> Best regards,
> Kathleen
>  
> On Tue, Oct 3, 2023 at 4:03 PM <dthaler1968=[e-mail] <mailto:[e-mail]>> wrote:
>> Michael Richardson writes: 
>> > 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.
>> 
>> I have to say I 100% agree with Michael here.  I admit I too had a fairly strong negative emotional
>> reaction reading the IAB statement, very similar to early drafts of draft-iab-protocol-maintenance
>> which I provided feedback about it being potentially harmful as worded, and we worked to
>> improve it to become a much better document RFC 9413.   I had provided feedback saying
>> that I agreed with much of the intent, but the way it was worded could be taken to promote
>> harmful principles that were not intended.   I have exactly the same feedback on this IAB
>> statement.
>> 
>> Some specific feedback follows.
>> 
>> > the use of such attestation as a barrier to access otherwise open protocols and services
>> > would negatively impact the evolution of the Internet as a whole
>> 
>> Analogy: disallowing access to those who cannot attest is in many ways analogous to
>> disallowing access to those who cannot use encryption.   Thus, by extension the IAB could equally say
>> "the requirement to use encryption everywhere as a barrier to access otherwise open services
>> would negatively impact the evolution of the Internet as a whole".   I, and I suspect many others,
>> would disagree with that principle, that encrypting everywhere is important to secure the
>> Internet and allow open services to continue being open and viable.   I would argue that
>> a comparison between attest-everywhere and encrypt-everywhere is valid.
>> (Full disclosure: I am the author of the statement "Every authentication use case is an
>> attestation use case." and my response here is consistent with that.)
>> 
>> > Adding client attestation into otherwise open systems can significantly reduce openness for the Internet broadly.
>> 
>> I think this is a red herring / mischaracterization.  The use of attestation does not reduce openness any more
>> than the use of authentication or encryption do.   You might argue that authentication and encryption both
>> DO reduce openness, and you might have a valid point there.   But in all three cases, I argue it's not the addition
>> of the technology itself that reduces openness, it's specific POLICIES that one can apply.   And those policies
>> could be done with authentication (e.g., restricting what type of identity, or what domain you connect from,
>> what IP address range you connect from, etc.) too.   In my view, the IAB would be better replacing the statement
>> about attestation with a statement about policy restrictions regardless of whether we're talking about authentication
>> or attestation.
>> 
>> > Attestation of client software and hardware is distinct from user authentication. User authentication verifies
>> > the identity of a user or a credential associated with a user, and is compatible with any implementation that
>> > supports the correct form of authentication.
>> 
>> I appreciate the IAB trying to do a compare/contrast here.  But I think the IAB misses a number of key points here.
>> User authentication does not mean the request actually originated from that user nor that the user consented to it,
>> and so is weak security without attestation.  Only authentication with attestation can ensure that it was not
>> compromised by malware subverting the user's intent, and so the IAB statement can be misread as an argument
>> against security, much like arguing against encrypting everywhere would.
>> More on "is compatible with any implementation" below.
>> 
>> > In contrast, attestation of client software and hardware places explicit restrictions on the implementations
>> > that are allowed to participate in the protocol.
>> 
>> Again, only in the same sense as requiring encryption does.  Specific POLICY can place restrictions on implementations,
>> but that's the policy not the existence of attestation itself.
>> 
>> > Restricting access via attestation of software or hardware would limit the development of new protocols and
>> > extensions to existing protocols, lock users into a limited ecosystem of applications, and hamper the ability
>> > to audit implementations, conduct measurements, or perform essential security research.
>> 
>> One could make the same statement about "Restricting access via requiring encryption would limit ..." or
>> "Restricting access via POLICIES around user authentication would limit...".  And I suspect there would be
>> lots of interesting discussion around those two claims too.   Calling out attestation here specifically seems
>> to me to more confuse the issue than help.
>> 
>> > The IAB invites those in the industry and standards community working on client attestation in open services
>> > to engage with the relevant IETF working groups (in particular, Privacy Pass and RATS)
>> 
>> To echo Michael's comment, I think those of us in the IETF RATS WG would invite those in the IAB to engage
>> with the WG to revise the IAB statement.
>> 
>> Thanks for listening,
>> Dave Thaler
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> RATS mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rats
> 
> 
>  
> -- 
>  
> Best regards,
> Kathleen