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

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?


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]