Subject: [Anima] Certification Authority renewal/rollover and intra-device communication

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Oct 2021 20:36:07 -0400

In:
https://github.com/anima-wg/constrained-voucher/pull/177/files

We make a compromise on the CA rollover protocol defined RFC4210.

Specifically, during the period when devices are renewing their certificates,
we do not support communication between devices with different certificates.
For instance two devices creating a new DTLS session between them, or even
IKEv2 or EDHOC using certificates.

Existing connections could continue, including rekeying, but new ones would
not be possible to create if the devices are in different states.

It's not clear to the design team how RFC7030 would have supported this
anyway: when would the OldWithNew and NewWithOld certificates have been
transfered, and at what point would devices learn that they no longer need to
include those in the certificate chains that are exchanged inband.

Given IoT networks that are primarily M2MP, we think that it *is* reasonable
that a non-constrained data collection system could have all the right
certificates (OldWithNew, NewWithOld) to operate.  But, we don't know how
that system got them.

{You might argue that this is really ace-est-coaps^WRFC9148 matter, and
probably you'd be right. But that document is past AUTH48, waiting for DTLS13}

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 3 Oct 2021 16:46:38 +1300

I *really* don't understand this stuff, but how long could the rollover
take, for a reasonably large IoT network (presumably thousands of
devices)? Are we talking about a few seconds when no new sessions could
start, or what?

That said, I don't see that you have much choice.

Regards
   Brian

On 03-Oct-21 13:36, Michael Richardson wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Oct 2021 12:24:37 -0400

> devices)? Are we talking about a few seconds when no new sessions could

For sleepy IoT devices that wake up once a day, and run on a slow network?
Could be a few weeks, easily.

But, on such networks, the devices mostly don't talk to each other at all.

Industrial situations like factories aren't doing a lot of device2device
communication (i.e. without involving the control system), but if they did,
then they'd want to schedule the certificate renewal/rollover at a specific time.

I think that we could do this by issuing new certificates with a notBefore
date in the future, but to date, I don't think we have a clear specification
that says this.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Oct 2021 09:04:44 +1300

> But, on such networks, the devices mostly don't talk to each other at all.

What, no networks of cooperating sensors ("I've detected smoke, did you
detect smoke too?")

> then they'd want to schedule the certificate renewal/rollover at a specific time.

Agreed, that would be normal procedure in control systems of all kinds.

It's less clear in what are euphemistically called tactical networks; a
certificate rollover on a battlefield could be a big deal.

> date in the future, but to date, I don't think we have a clear specification

Ack.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Oct 2021 10:48:16 -0400

> What, no networks of cooperating sensors ("I've detected smoke, did you

yeah, but since both sensors are sleeping, the coordination would be in the
central point.

    > certificate rollover on a battlefield could be a big deal.

the scene is the back of a truck (or sparse fuselage: think Edge of
Tomorrow), with 10 soldiers on each side: "Marines! Drop in five. Synchronize
your trust anchors!"