Re: [Iot-onboarding] [Secdispatch] DANE IOT proposed outcome

[Phillip Hallam-Baker <[e-mail]>]

TL DR; We used to ship devices with thirty different ciphers till we
realized that was wrong. Now its time to do the same with key rotation.

On Mon, Nov 30, 2020 at 10:33 AM Ash Wilson <[e-mail]> wrote:

>
>
> On Thu, Nov 26, 2020 at 7:13 PM Phillip Hallam-Baker <
> [e-mail]> wrote:
>
>>
>>
>> On Thu, Nov 26, 2020 at 5:35 PM Dan Harkins <[e-mail]> wrote:
>>
>>>
>>>   OK, I'll bite...
>>>
>>> On 11/26/20 2:17 PM, Phillip Hallam-Baker wrote:
>>>
>>> Lets break this down.
>>>
>>> Does the proposed solution work with existing Browsers?
>>>
>>> If yes, fine. But since this is DANE based, it can't be. So we have to
>>> modify the browser.
>>>
>>>
>>>   Why do we care about browsers for IoT onboarding? If my thing has no
>>> UI then a browser is the last thing I care about.
>>>
>>
>> If we aren't doing browser... manufacturer just issues an own label cert
>> with no expiry, job done. The custom client can use its own
>> pathmath validation.
>>
>> We should be looking for straightforward ways to rotate device keys over
> time in favor of longer key lengths or more resilient algorithms.
> Forever/y10k certs don't enable that. The entity name should not change
> over the life of the device, but the public key needs to. DANE doesn't
> interrupt existing rotation strategies and it simplifies certificate
> rotation for object security use cases.
> The expectation is that once this is supported in the client TLS and/or
> messaging library, the customization required on the part of the
> application owner will be minimal.
>

Why? What benefit do you expect to see from rotating the keys?

After 25 years doing PKI, I have come to regard key rotation as a
superstitious practice that is followed out of habit rather than to achieve
a specific security goal. Back in the 1990s, we didn't have a choice - most
machines were having difficulties with 1024 bit RSA and ECC was considered
witchcraft. We have X448 today, it works and is acceptably secure for the
lifetime of the device.

What is the security benefit of changing from one X448 key to another? I
can show you the cost. What is the benefit?

Changing the algorithm is going to require a firmware update.

There is a value to rekeying during onboarding. But that is a one time
operation that occurs when ownership of the device is changed. And that is
best achieved using threshold techniques so that the new owner's key is
additive to the device key.

I believe you have it the wrong way round: keep the device key constant and
let the user change the name at will. Then the strong name of the device is
simply the fingerprint of the public key. Every device will have a
permanent manufacturer strong name and an owner strong name created during
onboarding.


In the future, users are going to own hundreds of networked devices. I
already have 150 because 50% of the light switches in the house are
networked. Expect every room in future house to have at least one networked
lightswitch, a smoke/occupancy/temperature detector and a heating control.

So how do we expect the owner to manage the PKI for those devices?
Especially when we are going to refuse to give the user any feedback that
might disturb them, that being the dogma of the 'usability' brains trust:
make devices easier to use by denying the user necessary information.

If house scale IoT is going to be viable, we are going to have to simplify
it. Key rotation is one of the biggest cost drivers. So we should only
require it if there is a really solid case to be made that it provides a
measurable reduction in risk.