[saag] Re: [nasr] Re: Re: Re: Re: NASR BOF Follo w-Up

On Thu, Apr 10, 2025 at 11:02 AM Henk Birkholz <[email protected]>
wrote:

> Hi ekr,
>
> auditing the "correctness" of configuration or configurable state is an
> additional step that comes with its own security considerations, I think.
>
> The fact that a network device is trustworthy (it is doing what it is
> intended to do (by the Verifier Owner) and nothing else) does not
> directly translate to an operational state that is doing what every
> Relying Party expects it to do, I think.
>
> In remote attestation, the Verifier can be considered a trusted third
> party that takes on the burden of Evidence appraisal. As there are can
> be a quite colorful bouquet of Attester and Evidence types, that
> (sometimes quite significant burden/complexity) burden of Evidence
> appraisal is off-loaded to Verifiers so that the audience of Relying
> Parties can consume digestible Attestation Results tailored to their needs.
>
> If there is additional "relevant stuff" w.r.t. a network device which
> needs to be evaluated, that might be a task that remote attestation is
> only in support of - but that does not seem to be an explicit part of
> establishing trust in the trustworthiness in a remote peer/router. Or am
> I missing something very obvious here?
>

I don't know if you're missing something, but I don't really see how
this addresses my point, which is about the complexity of evaluating
the relevant Evidence, not about who does it. Specifically, my concern
is that it will not be practical to determine whether a given router
configuration enforces the high level semantics desired by the
Relying Party, e.g., that the data is going directly from this system
to system B without any ability for anyone else to see it. In order
to ensure this, someone has to know that all configuration values
that might implicate this guarantee are in known good states. That
could happen by, for instance:

- The Verifier seeing Claims for all the relevant configuration values
- The vendor determining which configuration values are relevant
and causing the device to emit a higher level Claim

But in either case, someone needs to take on the analysis of all
the configuration values. Has this been done for the types of devices
in question?

-Ekr


>
>
> Viele Grüße,
>
> Henk
>
> On 06.04.25 22:52, Eric Rescorla wrote:
> >
> >
> > On Sun, Apr 6, 2025 at 12:41 PM Michael Richardson
> > <[email protected] <mailto:mcr%[email protected]>> wrote:
> >
> >
> >     Eric Rescorla <[email protected] <mailto:[email protected]>> wrote:
> >          > However, it's not clear to me that that's true in this case,
> >     because
> >          > unlike media players, network devices are highly configurable
> >     and a
> >          > large number of the configuration directives might impact the
> >     relevant
> >          > security claims. Thus, determining whether an element is
> policy
> >          > conformant is a matter of knowing not just what code it is
> >     running
> >          > but the state of every relevant configuration directive. One
> >     could
> >          > imagine this working at least three ways:
> >
> >     I think you are making routers sound way more complicated than they
> are.
> >
> >
> >     1. 90% of directives have little to no affect.
> >         (I have one toe in the routing/operations space. I'm ASN26227)
> >
> >
> > Perhaps, but they still need to be individually examined in order to
> > to determine that. Has someone done that?
> >
> >
> >     2. they are significantly less complicated than Windows, yet all
> >     that media
> >         based DRM stuff you mentioned is dependant upon windows boot
> >     doing the
> >         right thing.
> >
> >
> > But essentially none of the relevant stuff that needs to be attested to
> > is configurable (by design). You just attest to the CDM contents.
> >
> >
> >          > In the former case, it is quite likely that there will be a
> large
> >          > number of valid states, because each directive may have
> multiple
> >          > acceptable values, and so you end up with combinatoric
> explosion
> >          > issues if you just have a list of hashes [0]. In the latter
> >     case we
> >
> >     yet, the *routing* people with the expertise here, and a few
> >     operators seem
> >     pretty sure they can do this.
> >
> >
> > It's not uncommon to see people be overconfident about things
> > prior to attempting them, especially in the area of security. Has
> > someone actually gone through the exercise of examining every
> > directive and determining which ones are relevant?
> >
> > -Ekr
> >
> >
> >          > Either approach requires studying the impact of every existing
> >          > configuration directive for each device type to know what the
> >          > impact will be on the relevant policy claims. This seems
> >     challenging
> >          > at best.
> >
> >     --
> >     Michael Richardson <[email protected]
> >     <mailto:mcr%[email protected]>>   . o O ( IPv6 IøT consulting )
> >                 Sandelman Software Works Inc, Ottawa and Worldwide
> >
> >
> >
> >
> >     _______________________________________________
> >     saag mailing list -- [email protected] <mailto:[email protected]>
> >     To unsubscribe send an email to [email protected]
> >     <mailto:[email protected]>
> >
>

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]