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

2021-10-06 Thread Michael Richardson

Brian E Carpenter  wrote:
>> Brian E Carpenter  wrote:
>> > 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?
>>
>> 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.

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

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

>> 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.

> 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.

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!"

>> 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.

> Ack.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


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

2021-10-05 Thread Brian E Carpenter
On 06-Oct-21 05:24, Michael Richardson wrote:
> 
> Brian E Carpenter  wrote:
> > 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?
> 
> 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.

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


> 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.

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.

> 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.

Ack.

   Brian

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


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

2021-10-05 Thread Michael Richardson

Brian E Carpenter  wrote:
> 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?

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.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


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

2021-10-02 Thread Brian E Carpenter
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:
> 
> 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. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
> ___
> Anima mailing list
> an...@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace