Internet Architecture Board


IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet

Home»Documents»IAB Correspondence, Reports, and Selected Documents»2023»IAB Statement on the Risks of Attestation of Software and Hardware on the Open Internet

25 September 2023

While attestation of client software and hardware is a useful tool for preventing abuse or fraud on the Internet, 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.

Openness and the empowerment of end users are core values of the IETF. RFC 3935, Section 4.1, explains this as part of the IETF’s mission statement:

“We want the Internet to be useful for communities that share our commitment to openness and fairness. We embrace technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community. These concepts have little to do with the technology that’s possible, and much to do with the technology that we choose to create.”

The Internet is built upon the idea that anyone who implements the appropriate standards should be able to interoperate on the Internet. Many of the core services that run on the Internet, such as email and the web, are designed to be openly accessible in this way. Adding client attestation into otherwise open systems can significantly reduce openness for the Internet broadly. A recent “Web Environment Integrity” proposal has highlighted this risk, although such models pose a risk beyond just the web.

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. In contrast, attestation of client software and hardware places explicit restrictions on the implementations that are allowed to participate in the protocol. For services that have intentionally restricted access, such client attestation (as described in Remote ATtestation procedureS (RATS), RFC 9334) is a valuable security measure, particularly when used in conjunction with user authentication. However, this approach is not appropriate for openly accessible services.

Allowing clients to use a variety of software as long as it is protocol-compliant is an essential part of the IETF development process and the openness of the Internet. Although customized or open-source software can also be used to circumvent client-side security measures, the continuing viability of open software is required for continued innovation. 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.

If client attestation signals are used in open services to mitigate fraud or abuse, they should be designed to only signal the authenticity of a user or client without imposing strict software or hardware requirements. They should also be designed such that attestation is not required, but has a clear backup behavior when attestation is not possible. IETF-based protocols such as Privacy Pass attempt to provide a protocol that can be deployed in ways that promote user privacy without exposing detailed identifiers about the client systems that are being used. Fundamentally, attesting specific properties about a networking client (e.g., there is some human user involved in this interaction) maintains the openness of the Internet, whereas attesting that a specific piece of software is in use does not and should be avoided.

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), and encourages those groups to focus on defining safe deployment models for attestation and abuse prevention that will not put the openness of the Internet at risk.