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

From: "Panwei (William)" <[email-masked]>
Date: Mon, 16 Nov 2020 12:02:25 +0000

Thanks to Eliot for summarizing these.

I think the core concept of using DANE in IoT scenario is to get rid of certificates and PKIX. The solution of how to securely onboard the IoT devices and allocate the DNS domain name, both with and without initial certificates, is the key part to figure out.
If the IoT devices have no initial certificates, such as 802.1AR IDevID certificate, as their initial identity, then the BRSKI mechanism won’t be appropriate for these devices because BRSKI has a requirement of IDevID.
If the IoT devices have an IDevID certificate, I think it can still use BRSKI to onboard, but it won’t use EST to request a certificate any more, instead, it will apply for a DNS domain name by using some protocols.

That’s my preliminary thoughts, maybe not right.

Regards & Thanks!
Wei Pan

From: Secdispatch [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Monday, November 16, 2020 6:55 PM
To: [email-masked]
Subject: [Secdispatch] DANE IOT proposed outcome

Thanks to Shumon for presenting the DANE use case for IOT.

We discussed taking this to the [email-masked]<mailto:[email-masked]> list as there were a number of rather big open issues that people wanted to discuss.

We also discussed a non-WG forming BOF to look at, as Ted put it, the broader context for onboarding.  To give people a feel for the sort of related work that is available, here are a list of related activities:

  *   draft-ietf-anima-bootstrapping-keyinfra (BRSKI) is a request/response mechanism that uses RFC 8366 vouchers to introduce devices and network infrastructure.
  *   Intel’s SDO provides an application level introduction using vouchers as well.  This work has been taken up by the FIDO alliance.
  *   The Wifi Alliance has Device Provisioning Protocol (DPP) which does not attach to a global name space prior to provisioning having occurred, but does represent a minimum case (just public keys).
  *   draft-friel-eap-tls-eap-dpp borrows from DPP, intended mostly for wired use, where DPP is focused on 802.11 networks.
  *   There are a number of BRSKI related drafts by Owen as well, relating to cloud-based registrars.
  *   There is also work by Michael Richardson and Peter Van Der Stock on constrained vouchers.  That work is taking place in ACE.

Understanding the landscape might help us understand where DANE fits in.

Regards,

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Nov 2020 13:50:30 +0100

Hi Wei Pan,

I agree with you that there is a need for something that doesn’t require devices to have a full PKI built in.  But there needs to be something unique about the device that it can express and prove.  Also, we should separate out two problems:

Proving the peer to the device
Providing the device to the peer

Each has slightly different characteristics, especially when it comes to certificates.  Nobody should expect a huge cert store to be on a light weight client.  As was said in the chat, that is one thing that BRSKI solves.  But DPP/POK also solves it without certificates, but still requires at least a public/private key pair. Less than that I do not know how to work the problem.

Eliot

> On 16 Nov 2020, at 13:02, Panwei (William) <[email-masked]> wrote:
> 
> From: Secdispatch [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Eliot Lear
> To: [email-masked] <mailto:[email-masked]>
> We discussed taking this to the [email-masked] <mailto:[email-masked]> list as there were a number of rather big open issues that people wanted to discuss.
> 
> draft-ietf-anima-bootstrapping-keyinfra (BRSKI) is a request/response mechanism that uses RFC 8366 vouchers to introduce devices and network infrastructure.
> Intel’s SDO provides an application level introduction using vouchers as well.  This work has been taken up by the FIDO alliance.
> The Wifi Alliance has Device Provisioning Protocol (DPP) which does not attach to a global name space prior to provisioning having occurred, but does represent a minimum case (just public keys).
> draft-friel-eap-tls-eap-dpp borrows from DPP, intended mostly for wired use, where DPP is focused on 802.11 networks.
> There are a number of BRSKI related drafts by Owen as well, relating to cloud-based registrars.
> There is also work by Michael Richardson and Peter Van Der Stock on constrained vouchers.  That work is taking place in ACE.
> 
> --
> Iot-onboarding mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/iot-onboarding <https://www.ietf.org/mailman/listinfo/iot-onboarding>

---

From: "Panwei (William)" <[email-masked]>
Date: Mon, 16 Nov 2020 14:46:16 +0000

Hi Eliot,

I understand there should be something unique to identity the device, it can be the certificate or public/private key pair or something else. I think the use of DANE in IoT scenario is to bind the device identity, i.e., the certificate or public key, to the DNS domain name.
In the BRSKI mechanism, after the device (pledge) and the network (registrar) authenticate each other, the device will apply for a local certificate from the network. What I mean is that the network may don’t need to have the PKI system to sign a certificate for the device, instead, the device can generate a key pair and the network allocates a DNS domain name to be related to the public key. So, after onboarding, the device will have a DANE TLSA record, therefore it can use that to authenticate itself to the server.
In the case without certificates, DPP/POK can solve the onboarding phase, then some other mechanisms may also be needed to provision the DNS domain name to the device.

Regards & Thanks!
Wei Pan

From: Iot-onboarding [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Monday, November 16, 2020 8:51 PM
To: Panwei (William) <[email-masked]>
Cc: [email-masked]; [email-masked]; Eliot Lear <lear=[email-masked]>
Subject: Re: [Iot-onboarding] [Secdispatch] DANE IOT proposed outcome

Hi Wei Pan,

  *   Proving the peer to the device
  *   Providing the device to the peer

Eliot

On 16 Nov 2020, at 13:02, Panwei (William) <[email-masked]<mailto:[email-masked]>> wrote:

Regards & Thanks!
Wei Pan

From: Secdispatch [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Monday, November 16, 2020 6:55 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Secdispatch] DANE IOT proposed outcome

Regards,

Eliot
--
Iot-onboarding mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/iot-onboarding

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 16 Nov 2020 15:47:15 +0100

Wrt. beyond thin device requiring at least a public key pair:

I thought there where also mechanisms by which the thin (IOT) device
might only have a unique symmetric key that is only shared with
some less constrained proxy ("in the cloud") that is supporting
the thin device in all more complex (crypto)  operations and avoid
the need for the thin device to support symmetric crypto - if thats
the component beyond its capabilities. 

Aka: Many ways to cut the cake. 

On Mon, Nov 16, 2020 at 01:50:30PM +0100, Eliot Lear wrote:
> Hi Wei Pan,
> 
> I agree with you that there is a need for something that doesn???t require devices to have a full PKI built in.  But there needs to be something unique about the device that it can express and prove.  Also, we should separate out two problems:
> 
> > If the IoT devices have no initial certificates, such as 802.1AR IDevID certificate, as their initial identity, then the BRSKI mechanism won???t be appropriate for these devices because BRSKI has a requirement of IDevID.
> > If the IoT devices have an IDevID certificate, I think it can still use BRSKI to onboard, but it won???t use EST to request a certificate any more, instead, it will apply for a DNS domain name by using some protocols.
> > 
> > That???s my preliminary thoughts, maybe not right.
> > 
> > Regards & Thanks!
> > Wei Pan
> > 
> > Intel???s SDO provides an application level introduction using vouchers as well.  This work has been taken up by the FIDO alliance.

> [email-masked]

-- 
---
[email-masked]

---

From: "Panwei (William)" <[email-masked]>
Date: Mon, 16 Nov 2020 15:17:16 +0000

Hi Toerless,

You're right, there're many ways to identify the device. But In the DANE client authentication case, the device's identity can only be the certificate or a public key pair, I think, because the DNS Server needs to store the public key hash values.
Except the initial identity, the device may be allocated a local identity after onboarding. So if the device has an initial identity of symmetric key, it has to be allocated a local identity of certificate or public key pair, then the local identity can be bound to a DNS domain name.

Regards & Thanks!
Wei Pan

-----Original Message-----
From: Secdispatch [mailto:[email-masked]] On Behalf Of Toerless Eckert
Sent: Monday, November 16, 2020 10:47 PM
To: Eliot Lear <lear=[email-masked]>
Cc: [email-masked]; [email-masked]; Panwei (William) <[email-masked]>
Subject: Re: [Secdispatch] [Iot-onboarding] DANE IOT proposed outcome

I thought there where also mechanisms by which the thin (IOT) device might only have a unique symmetric key that is only shared with some less constrained proxy ("in the cloud") that is supporting the thin device in all more complex (crypto)  operations and avoid the need for the thin device to support symmetric crypto - if thats the component beyond its capabilities. 

On Mon, Nov 16, 2020 at 01:50:30PM +0100, Eliot Lear wrote:
> > From: Secdispatch [mailto:[email-masked] 
> > <mailto:[email-masked]>] On Behalf Of Eliot Lear
> > <https://www.ietf.org/mailman/listinfo/iot-onboarding>
> 

-- 
---
[email-masked]

_______________________________________________
Secdispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Shumon Huque <[email-masked]>
Date: Mon, 16 Nov 2020 10:31:30 -0500

On Mon, Nov 16, 2020 at 10:17 AM Panwei (William) <[email-masked]>
wrote:

> Hi Toerless,
>
> You're right, there're many ways to identify the device. But In the DANE
> client authentication case, the device's identity can only be the
> certificate or a public key pair, I think, because the DNS Server needs to
> store the public key hash values.
>

Correct. DANE records store X.509 certificates, their public key
components, or raw public keys -- most commonly hashes of them, but can
store the full certificate/key too.

Shumon.

---

From: "Panwei (William)" <[email-masked]>
Date: Mon, 16 Nov 2020 15:51:34 +0000

Hi Shumon,

Thanks.

I was not so clear about how to use DANE before, mostly not clear about how to bind the device’s identity to the DNS domain name securely and automatically.
After Eliot’s explanation, I understand there are two parts: the device onboarding part and the DNS domain name provisioning part. And these two parts can be integrated, for example, when using BRSKI, the allocated DNS domain name can be bound to the LDevID.

Regards & Thanks!
Wei Pan

From: Shumon Huque [mailto:[email-masked]]
Sent: Monday, November 16, 2020 11:19 PM
To: Panwei (William) <[email-masked]>
Cc: Eliot Lear <lear=[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Secdispatch] DANE IOT proposed outcome

Hi Wei Pan,

I'll ask Ash (who is more plugged into the IOT ecosystem than I am) to confirm .. but yes, our use case expects devices to have IDevID or some other preconfigured unique value, so it should be possible to work with BRSKI. For the DNS record format naming, we were initially looking at the formats defined in draft-friel-pki-for-devices, specifically the LDevID organization managed form, but have a slightly simpler form currently specified in the draft.

Shumon.

On Mon, Nov 16, 2020 at 7:02 AM Panwei (William) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks to Eliot for summarizing these.

Regards & Thanks!
Wei Pan

From: Secdispatch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eliot Lear
Sent: Monday, November 16, 2020 6:55 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Secdispatch] DANE IOT proposed outcome

Regards,

Eliot
_______________________________________________
Secdispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Shumon Huque <[email-masked]>
Date: Mon, 16 Nov 2020 10:19:23 -0500

Hi Wei Pan,

I'll ask Ash (who is more plugged into the IOT ecosystem than I am) to
confirm .. but yes, our use case expects devices to have IDevID or some
other preconfigured unique value, so it should be possible to work with
BRSKI. For the DNS record format naming, we were initially looking at the
formats defined in draft-friel-pki-for-devices, specifically the LDevID
organization managed form, but have a slightly simpler form currently
specified in the draft.

Shumon.

On Mon, Nov 16, 2020 at 7:02 AM Panwei (William) <[email-masked]>
wrote:

> I think the core concept of using DANE in IoT scenario is to get rid of
> certificates and PKIX. The solution of how to securely onboard the IoT
> devices and allocate the DNS domain name, both with and without initial
> certificates, is the key part to figure out.
>
> If the IoT devices have no initial certificates, such as 802.1AR IDevID
> certificate, as their initial identity, then the BRSKI mechanism won’t be
> appropriate for these devices because BRSKI has a requirement of IDevID.
>
> If the IoT devices have an IDevID certificate, I think it can still use
> BRSKI to onboard, but it won’t use EST to request a certificate any more,
> instead, it will apply for a DNS domain name by using some protocols.
>
>
>
> *From:* Secdispatch [mailto:[email-masked]] *On Behalf Of *Eliot
> Lear
> *Sent:* Monday, November 16, 2020 6:55 PM
> *To:* [email-masked]
> *Subject:* [Secdispatch] DANE IOT proposed outcome
>
>
>
> We discussed taking this to the [email-masked] list as there
> were a number of rather big open issues that people wanted to discuss.
>
>
>
> We also discussed a non-WG forming BOF to look at, as Ted put it, the
> broader context for onboarding.  To give people a feel for the sort of
> related work that is available, here are a list of related activities:
>
>
>
>    - draft-ietf-anima-bootstrapping-keyinfra (BRSKI) is a
>    request/response mechanism that uses RFC 8366 vouchers to introduce devices
>    and network infrastructure.
>    - Intel’s SDO provides an application level introduction using
>    vouchers as well.  This work has been taken up by the FIDO alliance.
>    - The Wifi Alliance has Device Provisioning Protocol (DPP) which does
>    not attach to a global name space prior to provisioning having occurred,
>    but does represent a minimum case (just public keys).
>    - draft-friel-eap-tls-eap-dpp borrows from DPP, intended mostly for
>    wired use, where DPP is focused on 802.11 networks.
>    - There are a number of BRSKI related drafts by Owen as well, relating
>    to cloud-based registrars.
>    - There is also work by Michael Richardson and Peter Van Der Stock on
>    constrained vouchers.  That work is taking place in ACE.
>
>
>

---

From: Ash Wilson <[email-masked]>
Date: Mon, 16 Nov 2020 11:13:05 -0800

Hi Wei Pan,
The process of bootstrapping the device's identity is outside the scope of
our drafts, but I completely agree that getting the bootstrapping process
right is important. We think that using DANE like this doesn't conflict
with other bootstrapping processes; it just adds a DNS-discoverable public
key to the identity of the device when it is provisioned.

One of the processes we are seeking to simplify is that of establishing
trust directly between devices in the field, both of which may have only
a keypair, and not the benefit of PKI that chains to a publicly trusted CA.
Supporting x.509 certificates is in the interest of providing broad
protocol compatibility (including the support of other adjacent standards
like MUD: https://tools.ietf.org/id/draft-ietf-opsawg-mud-22.html#mudx509).
By using TLSA for client auth, we allow devices with only a raw public key
in DNS, as well as devices with metadata-rich x.509 certificates, to
mutually authenticate without requiring the distribution of CA
certificates, just based on knowledge of the communicating peer's DNS name.

SIM/UICC identity providers may provision public keys in DNS, and leave a
record of the device's DNS name in the SIM card (likely to be found in the
certificate). This gives the device that receives the SIM card the ability
to do all the things that the PKI ecosystem supports now, with the
additional benefit of being able to mutually authenticate without the other
side of the handshake needing to possess and trust the CA certificate used
to sign the certificate that ships with the SIM card. Naming collisions are
prevented by binding the public key to the DNS name- only the possessor of
the private key corresponding to the TLSA record is the 'real' identity
holder.

In a similar fashion, device manufacturers may provision a DANE identity
for devices before they ship. These device identities may reside in a DNS
zone under the manufacturer's control, or the implementer may present the
device certificates in a DNS zone under the implementer's control. This
allows the identity to more naturally indicate the party responsible for
the device's behavior, and can make the mitigation of some types of network
abuse a little more straightforward.

On Mon, Nov 16, 2020 at 8:04 AM Shumon Huque <[email-masked]> wrote:

> On Mon, Nov 16, 2020 at 7:02 AM Panwei (William) <
> [email-masked]> wrote:
>
>>    - There are a number of BRSKI related drafts by Owen as well,
>>    relating to cloud-based registrars.

-- 

*Ash Wilson* | Technical Director
*e:* [email-masked]

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: "Panwei (William)" <[email-masked]>
Date: Tue, 17 Nov 2020 01:54:54 +0000

Hi Ash,

Thanks for your clarifying. It’s clear to me now. Using DANE doesn’t conflict with other existing bootstrapping processes, but I feel some extensions may be needed to integrate.

Regards & Thanks!
Wei Pan

From: Ash Wilson [mailto:[email-masked]]
Sent: Tuesday, November 17, 2020 3:13 AM
To: Shumon Huque <[email-masked]>
Cc: Panwei (William) <[email-masked]>; [email-masked]; [email-masked]; Eliot Lear <lear=[email-masked]>
Subject: Re: [Iot-onboarding] [Secdispatch] DANE IOT proposed outcome

Hi Wei Pan,
The process of bootstrapping the device's identity is outside the scope of our drafts, but I completely agree that getting the bootstrapping process right is important. We think that using DANE like this doesn't conflict with other bootstrapping processes; it just adds a DNS-discoverable public key to the identity of the device when it is provisioned.

One of the processes we are seeking to simplify is that of establishing trust directly between devices in the field, both of which may have only a keypair, and not the benefit of PKI that chains to a publicly trusted CA. Supporting x.509 certificates is in the interest of providing broad protocol compatibility (including the support of other adjacent standards like MUD: https://tools.ietf.org/id/draft-ietf-opsawg-mud-22.html#mudx509). By using TLSA for client auth, we allow devices with only a raw public key in DNS, as well as devices with metadata-rich x.509 certificates, to mutually authenticate without requiring the distribution of CA certificates, just based on knowledge of the communicating peer's DNS name.

SIM/UICC identity providers may provision public keys in DNS, and leave a record of the device's DNS name in the SIM card (likely to be found in the certificate). This gives the device that receives the SIM card the ability to do all the things that the PKI ecosystem supports now, with the additional benefit of being able to mutually authenticate without the other side of the handshake needing to possess and trust the CA certificate used to sign the certificate that ships with the SIM card. Naming collisions are prevented by binding the public key to the DNS name- only the possessor of the private key corresponding to the TLSA record is the 'real' identity holder.

In a similar fashion, device manufacturers may provision a DANE identity for devices before they ship. These device identities may reside in a DNS zone under the manufacturer's control, or the implementer may present the device certificates in a DNS zone under the implementer's control. This allows the identity to more naturally indicate the party responsible for the device's behavior, and can make the mitigation of some types of network abuse a little more straightforward.

On Mon, Nov 16, 2020 at 8:04 AM Shumon Huque <[email-masked]<mailto:[email-masked]>> wrote:
Hi Wei Pan,

Shumon.

Regards & Thanks!
Wei Pan

Regards,

Eliot

--
Ash Wilson | Technical Director
e: [email-masked]<mailto:[email-masked]>

[图像已被发件人删除。]

This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Nov 2020 07:41:06 +0100

Hi Ash,

This all sounds fine.  I have a few thoughts, but nothing that invalidates the idea, I don’t think.  More about applicability.

> On 16 Nov 2020, at 20:13, Ash Wilson <ash.wilson=[email-masked]> wrote:
> 
> Hi Wei Pan,
> One of the processes we are seeking to simplify is that of establishing trust directly between devices in the field, both of which may have only a keypair, and not the benefit of PKI that chains to a publicly trusted CA.

Yes.  I think this is a great use of DANE.

> Supporting x.509 certificates is in the interest of providing broad protocol compatibility (including the support of other adjacent standards like MUD: https://tools.ietf.org/id/draft-ietf-opsawg-mud-22.html#mudx509 <https://tools.ietf.org/id/draft-ietf-opsawg-mud-22.html#mudx509>). By using TLSA for client auth, we allow devices with only a raw public key in DNS, as well as devices with metadata-rich x.509 certificates, to mutually authenticate without requiring the distribution of CA certificates, just based on knowledge of the communicating peer's DNS name.

What is configured at build time, what is configured at provisioning time, and what is accessed real time can mean trading off complexity against dependencies.  Absent OCSP there may be no external dependencies.  With OCSP (even with stapling) the situation might prove a little different.  This is worth discussion.

> SIM/UICC identity providers may provision public keys in DNS, and leave a record of the device's DNS name in the SIM card (likely to be found in the certificate). This gives the device that receive…

One thing we should look at is privacy considerations.  Who gets to query for this information?  What happens when they have it?  What is their authorization to have it?

> In a similar fashion, device manufacturers may provision a DANE identity for devices before they ship. These device identities may reside in a DNS zone under the manufacturer's control, or the impl…

This is very close to the MASA function in BRSKI.  Worth discussing.

I wonder if we should have “side meeting”, either this week or in one of the following weeks, to discuss all of this.  Would people be interested?

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 17 Nov 2020 08:43:30 +0100

> Yes.  I think this is a great use of DANE.

Would like to se a description of a more complete IoT use-casse workflow:

As a human i have a lot of backend processes that let's say make me "trust" that
"www.google.com" is a trustworthy source of search results (or not ;-).
In IoT environments its not entirely clear to me what this backend processes
would be to decide on whether a particular domain name is somethin to
"trust" to do something well...

> > Supporting x.509 certificates is in the interest of providing broad protocol compatibility (including the support of other adjacent standards like MUD: https://tools.ietf.org/id/draft-ietf-opsawg…

Ultimately from the trust perspective its not really that different. I for once wouldn't know how to compare
my trust into the DNSSEC trust anchors vs. those "browser vendor" ? maintained list of trust anchors. 

> What is configured at build time, what is configured at provisioning time, and what is accessed real time can mean trading off complexity against dependencies.  Absent OCSP there may be no external…

Yes, lot of devils in details.

> One thing we should look at is privacy considerations.  Who gets to query for this information?  What happens when they have it?  What is their authorization to have it?

It's called "public" keys ;-)) But indeed, DNS makes it easier for discovery of public keys == identities
of devices. And their names. I am probably more worried about the publicity of names.

> I wonder if we should have ???side meeting???, either this week or in one of the following weeks, to discuss all of this.  Would people be interested?

Time permitting, sure.

Cheers
    Toerless

---

From: "Panwei (William)" <[email-masked]>
Date: Tue, 17 Nov 2020 08:20:19 +0000

> I wonder if we should have “side meeting”, either this week or in one of the following weeks, to discuss all of this.  Would people be interested?

Sure. +1

Regards & Thanks!
Wei Pan

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Nov 2020 03:36:06 -0500

Eliot Lear <lear=[email-masked]> wrote:
    > There is also work by Michael Richardson and Peter Van Der Stock on

Just to clarify: it's occuring in ANIMA right now.

{I also think that there is a lot of potential crossover between constrained
vouchers/BRSKI, CORE RD, and ASYNC-Enrollment.
And draft-selander-ace-ake-authz is a bytes-on-the-wire-incompatible,
but semantically identical version of BRSKI for ultra-contrained
environments.  It has no obvious home at this point.}

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Nov 2020 03:40:25 -0500

> the component beyond its capabilities.

Yes, for instance: draft-ietf-6tisch-minimal-security.
Stuck in Cluster C310.  I think everything is unstuck now.
Can be mixed with constrained-voucher/brski in the same network.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Nov 2020 13:59:46 +0100

Ok, how about Thursday at 2:00pm GMT?  Does that work for people?  We can use a Webex or meet in meeting town.  Whatever people like.

> On 17 Nov 2020, at 09:20, Panwei (William) <[email-masked]> wrote:
>

---

From: Shumon Huque <[email-masked]>
Date: Tue, 17 Nov 2020 08:21:40 -0500

That works for me.

Ash - are you available?

Shumon.

On Tue, Nov 17, 2020 at 7:59 AM Eliot Lear <[email-masked]> wrote:

> Ok, how about Thursday at 2:00pm GMT?  Does that work for people?  We can
> use a Webex or meet in meeting town.  Whatever people like.
>
> > I wonder if we should have “side meeting”, either this week or in one
> of the following weeks, to discuss all of this.  Would people be interested?
>
> Sure. +1
>
> Regards & Thanks!
> Wei Pan
>
> --

---

From: Ash Wilson <[email-masked]>
Date: Tue, 17 Nov 2020 08:36:45 -0800

Sorry for the lapse- that time works for me as well!
-Ash

--

---

From: Ash Wilson <[email-masked]>
Date: Tue, 17 Nov 2020 10:53:44 -0800

Replies in-line...

On Mon, Nov 16, 2020 at 11:43 PM Toerless Eckert <[email-masked]> wrote:

> > > One of the processes we are seeking to simplify is that of
> establishing trust directly between devices in the field, both of which may
> have only a keypair, and not the benefit of PKI that chains to a publicly
> trusted CA.
> >

As a highly-decoupled smart cities application owner, I want to be able to
deploy environmental monitoring sensors (air quality, temperature, light,
noise level, etc...) across my city, and minimize the expense of deployment
and ongoing management.
  These sensors will use in-field (edge) nodes as aggregation points, and
those edge devices will summarize the information before sending it into
the central application, hosted in the cloud. All sensors will use the
city's municipal wifi to connect to edge nodes.
  I do not want to be bound to selecting the same vendor for all sensors (I
want best-of-breed), and I do not want to operate my own CA. For my risk
model, it's OK to use mfr-issued device certificates for all of my sensors.

  Network access use case:  I use cert-based EAP-TLS to provide network
access control for the networks my sensors and edge nodes connect to. In
order to prevent the possibility of naming collision across suppliers
(which creates an opportunity for device impersonation, improper network
access, and unreliable data) I need to onboard all of my devices to a
single CA. If I use DANE for device identity, I don't need my own private
CA, rather I only need to provide my RADIUS server with a list of allowed
device DNS names for the municipal sensor network, regardless of device mfr
or identity provider.

  Session security use case: My sensors connect to my edge nodes using TLS.
With traditional PKI, I need to make sure that the trust store in every
sensor has a CA cert for my edge nodes. My edge nodes need CA certs to
accommodate all sensors which might need to connect to them. Without DANE
for client identity, I need to either copy around CA certs from all of my
suppliers (name collision risk), or manage my own CA and onboard all of
those devices, which can be costly. With DANE for TLS client identity, I
can configure each sensor with the name of its upstream edge server (use
DANE as it is now), and I can configure each edge server with the names of
its allowed clients (use DANE for client ID). My sensors use mDNS to
discover edge node IP addresses, and use DANE to authenticate the
discovered edge nodes for establishing a TLS session.

  Message/object security use case: I want my edge nodes to forward
anomalies detected by sensors to the cloud-based central application, and I
need to be able to positively attribute the reported anomaly to the sensor
that reported it. This is useful for a variety of reasons, not the least of
which is identifying defective sensors. I use cryptographic signatures to
achieve message sender non-repudiation, which allows me to confidently
react to telemetry coming from the field, without needing to trust the
message integrity based on the security of the many middleware layers
the messages may pass through. In order to validate message signatures, my
central application needs a copy of every device's public key, and that is
usually provided by consuming certificates from a manufacturer's CA's
proprietary API. This can be challenging to manage, especially with
multiple CAs, and this ultimate aggregation point is where naming
collisions and device impersonation can have the greatest negative impact.
So I have a choice: I can implement my own CA and onboard all of my
devices, then I only have one API to synchronize certs from, or I can use
DANE for certificate discovery. If I use DANE, the message only needs to
bear a signature and the sending device's DNS name- the central application
can decide whether to consume the message based on the name of the sender
and the message can be authenticated by retrieving the public key from DNS.
This can simplify the challenge of associating entity names with public
keys within the central application, because instead of synchronizing CAs
with a cert store, the central application can use DNS to retrieve sensor
public keys as they're needed.

> like MUD: https://tools.ietf.org/id/draft-ietf-opsawg-mud-22.html#mudx509
> <https://tools.ietf.org/id/draft-ietf-opsawg-mud-22.html#mudx509>). By
> using TLSA for client auth, we allow devices with only a raw public key in
> DNS, as well as devices with metadata-rich x.509 certificates, to mutually
> authenticate without requiring the distribution of CA certificates, just
> based on knowledge of the communicating peer's DNS name.
>
> > What is configured at build time, what is configured at provisioning
> time, and what is accessed real time can mean trading off complexity
> against dependencies.  Absent OCSP there may be no external dependencies.
> With OCSP (even with stapling) the situation might prove a little
> different.  This is worth discussion.
>
> > > SIM/UICC identity providers may provision public keys in DNS, and
> leave a record of the device's DNS name in the SIM card (likely to be found
> in the certificate). This gives the device that receives the SIM card the
> ability to do all the things that the PKI ecosystem supports now, with the
> > One thing we should look at is privacy considerations.  Who gets to
> query for this information?  What happens when they have it?  What is their
> authorization to have it?
>

Good point. There are a few areas we should be mindful of as we proceed.
  Knowing the device's name is a sure way to access the public key, if the
public key is in DNS. But you must first know (or guess) the device's name.
Not putting unnecessary information in a certificate is a good way to
lessen the impact of a guessed device name.
  Don't put device certificates into CT logs. Unless there's a good reason
that's completely escaping me... that's a surefire way to signal the size
of your fleet, together with whatever metadata the certificates contain.
This is a risk that has nothing to do with making DANE work for Client ID
or cert discovery use cases, but it's worth mentioning. DANE makes the
certificate discoverable, without making the fleet easily enumerable.
  Passive DNS might be a vector for fleet enumeration, but it has its own
challenges.
  Let's ensure that the TLS implementation does a good job of protecting
the dane_clientid field. I think that's where we may have an opportunity
for discovery by packet capture, if it passes in plaintext. Discovery via
this method would provide a source and destination IP/NAT address as well
as an identity name, which could be used for certificate discovery. If we
pass the dane_clientid encrypted, this vector is mitigated.

> > > In a similar fashion, device manufacturers may provision a DANE
> identity for devices before they ship. These device identities may reside
> in a DNS zone under the manufacturer's control, or the implementer may
> present the device certificates in a DNS zone under the implementer's
> control. This allows the identity to more naturally indicate the party
> responsible for the device's behavior, and can make the mitigation of some
> types of network abuse a little more straightforward.
> > >
> >
> > I wonder if we should have ???side meeting???, either this week or in
> one of the following weeks, to discuss all of this.  Would people be
> interested?
>
> Time permitting, sure.
>
> Cheers
>     Toerless
>
> > Eliot
>
> --

--

---

From: "Panwei (William)" <[email-masked]>
Date: Wed, 18 Nov 2020 01:33:28 +0000

That time works for me.

Regards & Thanks!
Wei Pan

From: Iot-onboarding [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Tuesday, November 17, 2020 9:00 PM
To: Panwei (William) <[email-masked]>
Cc: Ash Wilson <ash.wilson=[email-masked]>; [email-masked]; Shumon Huque <[email-masked]>
Subject: Re: [Iot-onboarding] [Secdispatch] DANE IOT proposed outcome

Sure. +1

Regards & Thanks!
Wei Pan

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Nov 2020 07:38:54 +0100

Very good.  I will send a webex invitation to this group shortly.

Eliot

> On 18 Nov 2020, at 02:33, Panwei (William) <[email-masked]> wrote:
> 
> That time works for me.
> 
> Regards & Thanks!
> Wei Pan
> 
> On 17 Nov 2020, at 09:20, Panwei (William) <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 18 Nov 2020 12:10:08 +0000

Hi Eliot,

I find your use of the term peer confusing. Let me explain what I mean with this table on various terms for an EAP-TLS implementation:

   +-------------+---------------+-----------------+-------------------+
   |             | Device        | Gateway         | Server            |
   +-------------+---------------+-----------------+-------------------+
   | TLS         | Client        |                 | Server            |
   |             |               |                 |                   |
   | EAP/AAA     | Peer          | Authenticator   | EAP server/backend|
   |             |               |                 | auth server       |
   |             |               |                 |                   |
   | 802.1x      | Supplicant    | Authenticator   | Authentication    |
   |             |               |                 | server (AS)       |
   |             |               |                 |                   |
   | RADIUS      |               | Network access  | RADIUS server     |
   |             |               | server (NAS)    |                   |
   |             |               |                 |                   |
   | 802.11      | Station       | Access Point    |                   |
   +-------------+---------------+-----------------+-------------------+

Assuming email clients are able to render this ascii table correctly, I hope you understand that in some contexts, the device is the peer. When you say proving peer to device, and device to peer, I am unsure if you are referring to a server or a smartphone that acts as a companion device during bootstrapping.

I don't want to be the terminology police here asking people to be more cautious with the usage of terms. I also understand the reality that companies are often forced to do branding to look cool and perhaps improve chances of adoption.

Maybe as protocol engineers we can do somewhat better? I thought we already had too many terms for device: station/peer/client/supplicant. And then I saw the term pledge. Good luck trying to teach network security to new folks. No wonder many students I encounter now want to do AI or javascript but not low-level protocols. I am similarly not enthusiastic with usage of loose terms such as onboarding. At least in my study of several different systems including bluetooth/wi-fi/LWM2M: they principally follow the same terminology pattern: bootstrapping and authentication followed by provisioning/configuration. You could point me to OCF which uses onboarding but we don't have to make the same mistakes as another SDO.

--Mohit

On 11/16/20 2:50 PM, Eliot Lear wrote:
Hi Wei Pan,

Eliot

Regards & Thanks!
Wei Pan

Regards,

Eliot

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 18 Nov 2020 12:58:34 +0000

Hi Ash and Shumon,

My understanding is that your solution is applicable to any scenario that uses client certificates. Obviously IoT might be one application area for this, but there are many other uses of client authentication with certificates. I don't have any strong opinions about whether this is useful or not. But it might be good to have a separate focused DANE working group for these drafts if there is strong demand for such a solution. Your presentation also highlighted your intention of defining new RRtype and/or expanding the scope of TLSA. These things (along with DANE light etc.) would require the input of DNS and TLS folks (in addition to the IoT requirements).

Also, I didn't understand how would server authentication work? I probably did not listen to your presentation carefully enough but I suppose you cannot use DANE for server authentication in scenarios where the client device does not yet have Internet connectivity. So how would server authentication work in EAP-TLS/SIM card/IoT bootstrapping scenarios you discussed?

--Mohit

On 11/16/20 9:13 PM, Ash Wilson wrote:
Hi Wei Pan,
The process of bootstrapping the device's identity is outside the scope of our drafts, but I completely agree that getting the bootstrapping process right is important. We think that using DANE like this doesn't conflict with other bootstrapping processes; it just adds a DNS-discoverable public key to the identity of the device when it is provisioned.

Shumon.

Regards & Thanks!
Wei Pan

Regards,

Eliot

[https://lh5.googleusercontent.com/_vs__6iRjfmT2Ae5LLNBb8nEopl2M5Tl5QlpS6LS0Lh0vv4TYnZu-Mff2kDFOqe0LhbnSXprAx4yoaTvq_Tc_7n1b8yzGIqoxuhedthDxYQansg8ChT2x5EcZV3rjz19-Dx9rESL]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Nov 2020 14:03:30 +0100

Hi Mohit,

Your confusion is entirely understandable.  There the term means different things at different layers at this point.  Let me clarify:

In the general context, a peer is the other side of a connection.
In the EAP case, it’s the end device looking to be authenticated by an authenticator.

I think both uses are in context for this discussion… sadly.

Eliot

> On 18 Nov 2020, at 13:10, Mohit Sethi M <mohit.m.sethi=[email-masked] <mailto:mohit.m.sethi=[email-masked]>> wrote:
> 
> Hi Eliot,
> 
>>> On 16 Nov 2020, at 13:02, Panwei (William) <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/secdispatch <https://www.ietf.org/mailman/listinfo/secdispatch>

---

From: Shumon Huque <[email-masked]>
Date: Wed, 18 Nov 2020 08:52:09 -0500

> pass the dane_clientid encrypted, this vector is mitigated.

Just to elaborate on this point, with TLS 1.3 it should be possible to
fully protect the dane_clientid. In the next revision of the draft we will
move the use of the extension into the CertificateRequest and Certificate
messages which are both encrypted. TLS 1.2 on the other hand, will be a
challenge: ClientHello extensions and the client's Certificate message are
both in the clear (and ECH is not being designed for 1.2).

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 18 Nov 2020 09:09:54 -0500

On Wed, Nov 18, 2020 at 7:58 AM Mohit Sethi M <mohit.m.sethi=
[email-masked]> wrote:

> Hi Ash and Shumon,
>
> My understanding is that your solution is applicable to any scenario that
> uses client certificates. Obviously IoT might be one application area for
> this, but there are many other uses of client authentication with
> certificates.
>
Mohit - yes, there are certainly other application use cases and the
protocol is general purpose. Some SMTP transport security folks are
interested in this to give one example.

I don't have any strong opinions about whether this is useful or not. But
> it might be good to have a separate focused DANE working group for these
> drafts if there is strong demand for such a solution. Your presentation
> also highlighted your intention of defining new RRtype and/or expanding the
> scope of TLSA. These things (along with DANE light etc.) would require the
> input of DNS and TLS folks (in addition to the IoT requirements).
>

Yup, we will certainly need to get their input on this topic. I think I saw
a couple folks in the chat suggest resurrecting the DANE wg, which I'm open
to, but there was pushback too (I think more detailed discussion on list
was deemed necessary first).

Also, I didn't understand how would server authentication work? I probably
> did not listen to your presentation carefully enough but I suppose you
> cannot use DANE for server authentication in scenarios where the client
> device does not yet have Internet connectivity. So how would server
> authentication work in EAP-TLS/SIM card/IoT bootstrapping scenarios you
> discussed?
>

Yeah, the EAP-TLS case is trickier for DANE server authentication. There
are possible mechanisms though - the TLS DNSSEC chain extension (which
failed to gain consensus in the TLS WG a while back, but which will
probably be published through the IETF's independent stream) would provide
a way for the TLS server to deliver its DNS authentication chain inside the
TLS handshake, obviating the need for the client to perform DNS queries
prior to Internet connectivity. There are probably other solutions that
could be devised.

Shumon.

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 18 Nov 2020 15:10:07 +0000

Hi Shumon,

Why won't the same issue apply to the IoT bootstrapping and the SIM card use case you described.  You would likely authenticate the server before revealing the client identity. And that cannot happen with DANE because of lack of initial Internet connectivity. If this is the case, then I fail to understand some of the excitement for use in IoT bootstrapping. Also, I am not sure if verifying DNSSEC signatures sent inside the proposed TLS extension would be simple and lightweight for IoT devices?

--Mohit

On 11/18/20 4:09 PM, Shumon Huque wrote:
On Wed, Nov 18, 2020 at 7:58 AM Mohit Sethi M <mohit.m.sethi=[email-masked]<mailto:[email-masked]>> wrote:

Hi Ash and Shumon,

My understanding is that your solution is applicable to any scenario that uses client certificates. Obviously IoT might be one application area for this, but there are many other uses of client authentication with certificates.

Mohit - yes, there are certainly other application use cases and the protocol is general purpose. Some SMTP transport security folks are interested in this to give one example.

I don't have any strong opinions about whether this is useful or not. But it might be good to have a separate focused DANE working group for these drafts if there is strong demand for such a solution. Your presentation also highlighted your intention of defining new RRtype and/or expanding the scope of TLSA. These things (along with DANE light etc.) would require the input of DNS and TLS folks (in addition to the IoT requirements).

Yup, we will certainly need to get their input on this topic. I think I saw a couple folks in the chat suggest resurrecting the DANE wg, which I'm open to, but there was pushback too (I think more detailed discussion on list was deemed necessary first).

Yeah, the EAP-TLS case is trickier for DANE server authentication. There are possible mechanisms though - the TLS DNSSEC chain extension (which failed to gain consensus in the TLS WG a while back, but which will probably be published through the IETF's independent stream) would provide a way for the TLS server to deliver its DNS authentication chain inside the TLS handshake, obviating the need for the client to perform DNS queries prior to Internet connectivity. There are probably other solutions that could be devised.

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 18 Nov 2020 10:48:10 -0500

I assume we can cover this at tomorrow's side meeting. I'm not fully
informed of the details of the network access authentication use case
specifically (I'm sure Ash will elaborate), but I assume there are other
possibilities for authenticating the server side in those environments,
such as straight PKIX auth with a pre-provisioned small trust anchor set.

Shumon.

On Wed, Nov 18, 2020 at 10:10 AM Mohit Sethi M <[email-masked]>
wrote:

> Hi Shumon,
>
> Why won't the same issue apply to the IoT bootstrapping and the SIM card
> use case you described.  You would likely authenticate the server before
> revealing the client identity. And that cannot happen with DANE because of
> lack of initial Internet connectivity. If this is the case, then I fail to
> understand some of the excitement for use in IoT bootstrapping. Also, I am
> not sure if verifying DNSSEC signatures sent inside the proposed TLS
> extension would be simple and lightweight for IoT devices?
>
> --Mohit
> Yup, we will certainly need to get their input on this topic. I think I
> saw a couple folks in the chat suggest resurrecting the DANE wg, which I'm
> open to, but there was pushback too (I think more detailed discussion on
> list was deemed necessary first).
>

---

From: Ash Wilson <[email-masked]>
Date: Wed, 18 Nov 2020 10:37:53 -0800

Hi Mohit,
  You are correct- using DANE for server authentication in use cases
without Internet connectivity (EAP-TLS, for instance) is challenging, and
may require other modifications to the process. It may make more sense for
the EAP-TLS use case to use another mechanism like the TLS DNSSEC chain
extension, or traditional PKI, to get around the lack of internet
connectivity for the server part of mutual authentication.

  Using DANE for client identity is expected to work well because the
authentication server typically has sufficient connectivity to interact
with DNS.

  These proposals aren't intended to replace any identity bootstrapping
protocols. Rather, they are intended to work in concert with existing
protocols to make public keys easily discoverable.

On Wed, Nov 18, 2020 at 7:48 AM Shumon Huque <[email-masked]> wrote:

>>> My understanding is that your solution is applicable to any scenario
>>> that uses client certificates. Obviously IoT might be one application area
>>> for this, but there are many other uses of client authentication with
>>> certificates.
>>>
>> Also, I didn't understand how would server authentication work? I
>>> probably did not listen to your presentation carefully enough but I suppose
>>> you cannot use DANE for server authentication in scenarios where the client

--

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Nov 2020 14:58:33 -0500

> certificates, is the key part to figure out.

I would say this differently: it is to relieve the manufacturer of the burden
of operating a certification authority.
They outsource that to their DNS Operations.

    > certificate, as their initial identity, then the BRSKI mechanism won’t
    > be appropriate for these devices because BRSKI has a requirement of
    > IDevID.

It's certainly easier to get manufacturer data from a manufacturer signed IDevID.
Conceptually, there is nothing preventing a Registrar from accepting (through
supply chain integration), a database of Raw Public Keys for the devices.
Eliot and I have discussed this possibility two weeks ago for some entities
that are reluctant to take on operating the HSM they think is necessary to do
proper PKI.{%}

The proposed TLS extension would allow a DNS QNAME to be associated with the
key, so the "database" mentioned above could be the *DNS*.  An associated TXT
or new RR-type could point to the MASA, or we could have some convention
like, given "dev8955HBCDA.p.devices.example", take off two labels and add
"masa", giving us "masa.devices.example" as the place to contact.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Nov 2020 17:17:37 -0500

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. So the question to ask is:

Is this the best solution that involves modifying the browser?

I don't care how much effort went into DANE, that is really inconsequential
when we consider the cost of modifying billions of browsers that are in use.

PKIX is a really lousy match for IoT requirements. It is designed to
authenticate organizations and people within organizations. Hence it begins
with the assumption credentials expire and must be renewed on a regular
basis. That is a bad starting point for IoT.

But DNS is rather worse, the time scale is even shorter because it is set
by the need to push out service configuration changes. And the number of
IoT customers who have access to DNS configurations is a small part of the
target market. And DNS names expire every year and require a paid renewal.
This is going backwards, not forwards.

DANE has had plenty of time to prove itself useful. At this point it is
time to declare that it has lost any claim to own this space. It is time to
ask if other people have a better idea. Including the people who were
repeatedly told they were not welcome to participate in DANE because they
had different ideas.

---

From: Dan Harkins <[email-masked]>
Date: Thu, 26 Nov 2020 14:34:52 -0800

OK, I'll bite...

On 11/26/20 2:17 PM, Phillip Hallam-Baker wrote:
> 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.

   regards,

   Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Nov 2020 19:12:48 -0500

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

---

From: Ash Wilson <[email-masked]>
Date: Mon, 30 Nov 2020 10:32:55 -0500

On Thu, Nov 26, 2020 at 7:13 PM Phillip Hallam-Baker <[email-masked]>
wrote:

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

--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 30 Nov 2020 11:20:11 -0500

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 <[email-masked]> wrote:

>
>
> On Thu, Nov 26, 2020 at 7:13 PM Phillip Hallam-Baker <
> [email-masked]> wrote:
>
>>
>>

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.

---

From: Ash Wilson <[email-masked]>
Date: Mon, 30 Nov 2020 23:07:13 -0500

Hi Phillip,
Thanks for the detailed reply, my comments are in-line below...

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

There is a quantifiable cost to guessing private keys. If the cost to guess
the private key is less than the potential financial gain resulting from
compromise, there is financial incentive to attack. Shorter keys are
cheaper to guess, and algorithms are not always well-implemented (
https://crocs.fi.muni.cz/public/papers/rsa_ccs17). If keys can be rotated,
the attacker must guess and use the private key while it's still valid.
This raises the cost associated with guessing the private key (need more
resources running in parallel) and it lowers the value of a compromised
private key because a compromised key is not good forever.

> can show you the cost. What is the benefit?

At some point in the not-too-distant future there is expected to be a
pressing need to move toward quantum-resistant algorithms. We don't know
what those algorithms are yet, and commonly-used cryptography libraries may
not yet support them. In order to ease the migration to stronger public key
algos, we will definitely need good firmware update mechanisms (SUIT/TEEP,
etc) as well as effective credential rotation processes. We have protocols
to aid in cert rotation, and using those in conjunction with DANE can make
cert discovery after rotation (especially for object security) much more
straightforward.

> Changing the algorithm is going to require a firmware update.

Agree 100%.  Firmware updates must be possible through the expected life of
the device, otherwise we end up repeating the same mistakes that made Mirai
so far-reaching and difficult to address.

> additive to the device key.

I agree that there are benefits to adding an ldevid in addition to an
idevid. It really depends on the application and motivation for re-keying.
Using DANE prevents naming collisions across CAs, and it can make
authentication across PKI roots of trust easier. If those are the only
reasons for re-keying during onboarding, the implementer or application
owner may be able to save money on the onboarding process by selecting a
supplier which uses DANE together with PKI for extending the usefulness of
the idevid.

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

I see your logic, but the need to increase key length over time causes
friction with this approach. If the name used to discover the public key
never changes, the keypair or public key algorithm can change whenever the
rules of good security hygiene dictate. Application participants only need
to know the DNS names of the entities they should be interacting with, and
may continue to authenticate after credential rotation, after
the exhaustion of the old certificate's TTL in DNS.

> make devices easier to use by denying the user necessary information.

Great question! I don't see home IoT consumers directly managing PKI at
all. Requiring a home IoT user to directly configure PKI is a sure way to
negatively impact the user experience. On the other hand, I could
definitely see manufacturers using DANE for device identity because it can
allow their products to authenticate with products from other vendors who
ship devices with DANE identities.

Customers would be able to configure home application controllers with a
list of allowed device DNS names, then configure the new device with the
hub controller's DNS name, and then all that's required is API
compatibility and DANE device identity. I think that using DANE like this
allows consumers to get the benefits of mfr-managed PKI, and a simplified
onboarding experience. In lieu of an involving pairing ritual, the consumer
may describe the home ecosystem in terms of device DNS names.

> measurable reduction in risk.

I agree. There are some use cases where key rotation may not make sense.
The hope is that by pairing the security benefit of easier credential
rotation with the operational benefit of simplified onboarding, we'll see
broader adoption of better security mechanisms.

--