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

[[e-mail]]

Michael Richardson writes: 
> 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.

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