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

[Kathleen Moriarty <[e-mail]>]

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]>
wrote:

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


-- 

Best regards,
Kathleen