Re: [Anima] Brian/anima: trust notion of ASA communications

Toerless Eckert <> Fri, 07 February 2020 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81D2612029C for <>; Fri, 7 Feb 2020 06:58:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yD5-dBm-nd-X for <>; Fri, 7 Feb 2020 06:58:09 -0800 (PST)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9055B1207FC for <>; Fri, 7 Feb 2020 06:58:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C164454804C; Fri, 7 Feb 2020 15:58:02 +0100 (CET)
Received: by (Postfix, from userid 10463) id B9400440059; Fri, 7 Feb 2020 15:58:02 +0100 (CET)
Date: Fri, 7 Feb 2020 15:58:02 +0100
From: Toerless Eckert <>
To: Michael Richardson <>
Message-ID: <>
References: <> <23372.1581026131@dooku>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <23372.1581026131@dooku>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [Anima] Brian/anima: trust notion of ASA communications
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Feb 2020 14:58:12 -0000

On Thu, Feb 06, 2020 at 10:55:31PM +0100, Michael Richardson wrote:
> I agree.
> But, at this point, all the ANI peers are equal.

Except for cmc(RA).

> None do anything special yet... Once we have protocol(s) that can do
> something different, then we need to figure out what the requirements for
> that protocol.

Or rather service. yes. Thats what i am asking for.

> Putting the trusted-to-do-foo bit into the certificate is probably unwise.

a) see above (registrar)
b) I think its wise, but i do understand how the crypto folks don't lke it
   and every time you ask crypto folks think outside the box it takes
   eternities. Aka: to me its not different from the implied trust
   expressed by a weeb certificate through the name. If i have cert bits
   indicating more generic "roles" thats IMHO quite similar.
c) But the main ask here was to see if there is some actionable output
   of research that moves us beyond this model.

> It seems that in an autonomic network that there ought to be a service that
> can be used to ask, "should I trust node FOO to do X?".

Sure, and i am going to run a hacked ACP node thats announcing in GRASP
to be the "best-ever" node to provide that service ;-) How to you
prohibit me to happen ? -> Anser: i dont have a fitting certificate, or
there is some ACP crowd intelligence that says i am untrustworthy.

> That could be the (cmc)RA or another node so designated.

Right. Thats the "role" indications in certificate approach. And of
course we want to limit that to really "lifetime role assignments"
(lifetime larger than cert lifetime..).

> It seems that GRASP can pretty much do all of this.
> COSE can be used to sign answers.
> That is probably a thing we need to add.


>     > I think DINRG is working in this direction, but have failed to track.
>     > Maybe there is a way to collaborate on this, aka: see if/when they might
>     > have output we could think to adopt/leverae.
> I don't know what they are doing either.
>     > Right now we expect objective announcements from any node to be equally
>     > trustworthy and decide on selecting one only on announced parameters
>     > (also subject to equal trust) and network parameter comparison.
>     > And of course, this goes beyond trust into performance vetting by
>     > others and so on.
> At some level, if you are looking for resource X, and some node can provide
> X, and it works and does what you need... then maybe it is reasonable to
> trust it.

Yes, discovering violation of trust is the biggest issue for crowd intelligence.

The easier starting point case would be crowd intelligence based on
client measured service performance experience. Think DNS proxies on
each edge-router circling around the set of DNS services announced, DNS
proxies measure RTT and failure rate, exchange amongst themselves those
parameters and adjust their use of these servers accordingly. Easy to
see how this might easily wipe out unreliable servers. Much more difficult
to do the solution to optimize overall load when the best server becomes
overloaded because everybody wants to start using it.


> --
> Michael Richardson <>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-

> _______________________________________________
> Anima mailing list