Subject: [Drip] complexity class needed to run DRIP?

From: "Card, Stu" <[email-masked]>
Date: Sun, 21 Feb 2021 11:43:18 -0500

I am out walking a snowy trail so my head is clear enough to think. :-)

Worrying about packaging of re-usable software components & mobile code, my
first thought is that for an entity to provably identify itself in a manner
not subject to replay attacks, it must be somewhat heavyweight --
presumably at least a Universal Turing Machine.

Maybe not? It doesn't need to be able to run _any_ program, just a program
that can execute its end of very specific protocol specifications for a
very narrow proximate purpose.

So what complexity class machine might suffice as a Broadcast RID
transmitter with our trust mechanisms?

---

From: Michael Richardson <[email-masked]>
Date: Sun, 21 Feb 2021 14:43:06 -0500

Card, Stu <[email-masked]> wrote:
    > Worrying about packaging of re-usable software components & mobile
    > code, my first thought is that for an entity to provably identify
    > itself in a manner not subject to replay attacks, it must be somewhat
    > heavyweight -- presumably at least a Universal Turing Machine.

I'm not convinced of that.

We need freshness.  There are some ways to get this.
  1) by providing some kind of nonce which is incorporated into the
     signed object.

  2) by including an agreed-upon time base into the signed object.

(2) is really just a predictable incremental nonce in some way.

Getting a nonce seems to require a round trip, but in the RATS Architecture,
we described a few ways involving broadcasting of handles:

https://www.ietf.org/archive/id/draft-ietf-rats-architecture-10.html#name-appendix-a-time-considerati

In the handle-based idea, the handles are not monotonically-increasing times,
but something else.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide