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

On 10.04.25 21:28, Eric Rescorla wrote:
> 
> 
> 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.

Isn't that a proof of "non transit"? I am not as familiar with NASR as 
others, but I thought that was out-of-scope at least for the initial 
chartering?

You are also talking about Evidence again. From my perspective, it 
sounds simpler to me to "use RATS" to establish trust in the 
trustworthiness of the networks device's TCB. Have a "trusted telemetry" 
element in the TCB (e.g., a YANG Push'able Service) that can expose the 
required configuration and operational state to authenticated 
authorities, and then acquire trusted telemetry without re-generating 
Evidence about the trustworthiness of the network device all the time.

Generating some specific (TPM-based) Evidence on-change via YANG is 
enabled by RFC 9684 and sooo(tm) RFC-to-be 
draft-ietf-rats-network-device-subscription.

That the evaluation of configuration and operational state is complex I 
definitely assume to be true and we have a whole area in the IETF that 
can help us with that, I think.

> 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?

I am not that level of a YANG expert, but I think the building blocks 
for that should be there (with maybe a few gaps to fill). I'd defer that 
question to someone more informed than me.


Viele Grüße,

Henk

> 
> -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]>
>     <mailto:mcr%[email protected] <mailto:mcr%[email protected]>>>
>     wrote:
>      >
>      >
>      >     Eric Rescorla <[email protected] <mailto:[email protected]>
>     <mailto:[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]>
>      >     <mailto:mcr%[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]>
>     <mailto:[email protected] <mailto:[email protected]>>
>      >     To unsubscribe send an email to [email protected]
>     <mailto:[email protected]>
>      >     <mailto:[email protected] <mailto:[email protected]>>
>      >
> 

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