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

On 16.04.25 23:02, Watson Ladd wrote:
> On Wed, Apr 16, 2025 at 5:19 AM Henk Birkholz
> <[email protected]> wrote:
>>
>> On 15.04.25 19:18, Watson Ladd wrote:
>>> On Mon, Apr 14, 2025 at 10:50 PM Liuchunchi(Peter)
>>> <[email protected]> wrote:
>>>> So this may yield two major trust assumptions:
>>>>
>>>>
>>>>
>>>> [My device] Operators have administrative control over all devices in his domain, regardless of vendors.
>>>> [Truthful intention] Operators extract real router configurations out of truthful intention, using whatever best techniques available.
>>>>
>>>>
>>>>
>>>> [Ongoing techniques] Extraction techniques, we have to-be-RFC TPM-CHARRA draft that conducts YANG-based extraction. There is WIP YANG-provenance draft that confirms YANG config coming from a right source. There is WIP multiple-verifiers draft that works with many vendors in one single domain.
>>>>
>>>>
>>>>
>>>> Is this trust assumption and scope-narrowing statement good for you?
>>>
>>> But at this point what is this doing that RANCID doesn't? Why do we
>>> need transit proofs and all that, if we're never exiting a domain?
>>
>> RANCID has been doing a great job for decades, but by would you believe
>> that a network device is exposing its actual (potential latent) and
>> operational state to you? All devices could already lie to you because
>> they are compromised. If your are an organization that could be subject
>> to audits or some other forms of accreditation or accountability, than
>> maybe you would like to show that acquired data about your systems is
>> authentic and also auditable after the fact. That can include critical
>> data flows in side your domain or to its "edges" (following the
>> assumption that a healthy network device will not forward transfer units
>> over non-endorsed or otherwise secured interconnects).
> 
> I'm confused. Why does RATS magically solve this problem? You can have
> the world's most secure boot chain, and if the software is compromised
> it might still lie/you will be mislead about the consequences of the
> configuration being in a state because by assumption the software
> doesn't behave properly. That's the gap which I think Eric and I think
> can't be crossed: going from the configuration to the property, not
> getting the config out (which sure, throw RATS at it)
> 

TL;DR this reply is too long; I skimmed it briefly after writing. I am 
still confuzzled about mixing the topics Evidence about actual 
operational state and Compliance to domain-specific policy. Happy Easter 
everyone!


As an aside: I'm having a hard time following "you will be mislead about 
the consequences of the configuration being in a state because by 
assumption the software doesn't behave properly". Not behaving properly 
by lying? I am mislead by the false assumption that network equipment is 
lying to its owner? By believable Evidence being incorrect (unobersvable 
compromize of roots of trusts)? As there are sometimes nuances here, I 
cannot parse.

Maybe an initial confusion might stem from the scope of RATS, which is 
not limited to "secure boot". At least you conduct measured boot and 
mostly authenticated boot, I think. Secure boot is a an old term that 
comes with an old Angst (similar to the JOSE/COSE Angst [1] wrt to 
signing) that your device can stop booting at any point due to local 
policy violation. Not a lot of network carriers, cell phone tower 
owners, or car manufacturers were willing to build systems around an 
architecture that can render their system unavailable (although that is 
just an optional implementation choice, to begin with).

What RATS cannot "know" is that the intended software actually includes 
weaknesses (important but not necessarily urgent) or vulnerabilities 
(important and urgent but not necessarily exploitable) that also are 
exposed via an attack surface (you are done). If that is according to 
intended state, your problem lies somewhere else (e.g. software 
management). I assume we converge on that point?

What RATS can "know" is that a software component residing on an 
Attester was compromized during runtime of the system. There is a lot of 
work out there about so called "run-time integrity". It's not a 
one-size-fits-all problem space, but depending on your roots of trusts 
or type of Evidence generation, malicious or unauthorized changes to the 
system can be detected during runtime. There are even approaches to 
detect unintended changes of running processes. Admittedly, the latter 
is the most difficult variant and there are significantly more 
scientific papers in that space than standards. I assume we diverge on 
this point?

That all said, combining state-of-the-art vulnerability management 
(using building blocks, such as SBOMs, OmniBOR, VEX, in-toto build 
artifact provenance statements, etc.) with RATS can and do up-level your 
assurance levels to high (with a fraction of the cost(tm) that it did a 
decade ago) and I think that is the point here.

Will that box of tools (RATS, SW & Policy management) detect every 0day 
pawn via appraisal of run-time integrity of a network component? No. 
Will it increase your trust in the trustworthiness of a remote peer by a 
magnitude? Absolutely.

Watson, I think in your scenario the attacker is "the policy I cannot 
see" of a counterparty. If you do not trust your peer (i.e. trust anchor 
or identity management) in general, my advice is to handle it with care 
in the first place and not to send sensitive data to it. That is not a 
RATS problem. That is a local policy and trust management problem. From 
the point of view of the RATS WG, I think this whole NASR wave was aimed 
to help the aforementioned network carriers, cell phone tower owners, or 
car manufacturers; to engineer new solutions for that problem space, to 
finally put more tools in the toolbox that address the problem space.

As Max would say, I am perpetually confuzzled [2] how "using RATS" is 
interpreted as an approach that solves "trust between peers" in an 
absolute manner, by itself, magically. RATS always require a scope of 
application and maybe additional domain-specific standards text. I took 
the time to go through this thread and to be blunt: I sometimes 
encountered misconceptions or unwarranted entanglement of RATS and 
configuration/trust relationship management and that is why I am writing 
this tedious wall of text.

The only viable agreement I could derive from this thread is captured in 
[3]. Sorry again for the wall of text and to sound a bit grumpy. I'll 
let that go now and embark on some vacation! If I had more time, I would 
have written a shorter and more agnostic reply.


Viele Grüße,

Henk


[1] https://mailarchive.ietf.org/arch/msg/cose/8ywbcUy-YQZUh0JF4W5Tto1dCvg
[2] 
https://www.merriam-webster.com/wordplay/confuzzled-definition-words-watching
[3] https://mailarchive.ietf.org/arch/msg/nasr/-mGg3dj148yiCUwotmtcDAv6VOI


> 
> 
> 
> --
> Astra mortemque praestare gradatim
> 

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