[nasr] Re: [saag] Re: NASR BOF Follow-Up

[Henk Birkholz <[e-mail]>]

On 11.04.25 19:23, Eric Rescorla wrote:
> 
> 
> On Fri, Apr 11, 2025 at 10:19 AM Henk Birkholz 
> <[e-mail]> wrote:
> 
>     On 11.04.25 18:51, Eric Rescorla wrote:
>      >      >
>      >      >     Would some salt help here (like the salted hashes in
>     sd-cwt)?
>      >      >
>      >      >
>      >      > Probably not very much. What salt does is make it more
>     difficult to
>      >      > amortize computation
>      >      > across multiple hashed values. However, if the total number of
>      >     possible
>      >      > values
>      >      > is low (e.g., you have some configuration setting with 3
>     values)
>      >     then
>      >      > you can
>      >      > just exhaustively search at query time.
>      >
>      >     That makes a lot of sense - and might be another good reason
>     not to put
>      >     these types of Claims into Evidence. I still think it is
>     better to
>      >     include software components that provide the conveyance mechanism
>      >     (e.g.,
>      >     a YANG server with YANG Push capability) in a TCB and then use
>      >     successfully appraised software components for trusted
>     telemetry to
>      >     convey such values for evaluation.
>      >
>      >
>      > That may be better from some angles but I think brings us back to
>      > Richard's question about whether operators are in fact willing to
>      > allow counterparties to access their devices to get this
>     configuration data.
>      >
>      > It also doesn't affect--one way or the other--the need to understand
>      > which configuration directives are relevant and what acceptable
>      > values are.
>      >
>      > -Ekr
> 
>     If it is really a requirement that policy must be evaluated on the
>     level
>     you describe, my assumption is that a trusted third party that is a
>     kind
>     of "policy evaluator", not a counterparty, and also taking on the role
>     of an Attester (that can be "RATS approved") could handle such
>     operations. But this is now bordering on speculation on my part as
>     there
>     are many ways to compose such a system and I am not aware of all the
>     requirements.
> 
> 
> Well, this doesn't matter for the point I'm making. *someone* needs
> to do the evaluation and I'm questioning whether it's actually
> practical.
> 
>     My point being here is that RATS is not some kind of smokescreen or
>     some
>     kind of solve-it-all. It is just a building block to increase trust in
>     the trustworthiness of a remote peer.
> 
> 
> You may be addressing Richard here? As I said above I'm interested
> in the question of whether it's in principal practical to determine
> whether a given device's configuration is acceptable even under the
> assumption that you have trustworthy access to that configuration.
> 
> -Ekr
> 


Hi Ekr,

sorry for dragging you through this convo, but I think I now have a 
better understanding of your problem statement than before. Thanks!

As far as I am understanding it for now, the question is: "is it 
possible to determine that the configuration/policy of a device is 
acceptable in a fashion that does not expose that configuration/policy 
to a counterparty?" That question would be independent from "RATS 
Evidence" which was popping up in the thread before.

And yes, I think the smokescreen comment originated Richard.


Viele Grüße,

Henk