Subject: [Danish] IoT Device Identification with TLSA via Danish

From: Jacques Latour <[email-masked]>
Date: Mon, 14 Jun 2021 14:40:38 +0000

Hi,

Today I presented at the ICANN DNSSEC workshop the potential results of DANISH working group which I think should include the entire scope having a mutual TLSA validated TLS session from an IoT device to a server.

https://github.com/CIRALabs/CIRA-Secure-IoT-Registry/blob/master/CIRA%20-%20Challenges%20in%20DNSSEC%20IoT%20Registry%20-%20ICANN%202021-6-14.pdf

In addition, I was thinking there should be a 4th TLSA certificate usage, type 0 or 4, for TLSA to show cert that are revoked, if we know for sure the certificate is revoked then it should be presented and queried/answered as such,  an authoritative answer signed with DNSSEC to say certificate is revoked, not to be trusted anymore.  NSEC says it does not exists, this usage would be very clear. This works for client identity, not sure for other TLSA use cases.

Jacques

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Jun 2021 11:35:17 -0400

On Mon, Jun 14, 2021 at 02:40:38PM +0000, Jacques Latour wrote:

> Today I presented at the ICANN DNSSEC workshop the potential results
> of DANISH working group which I think should include the entire scope
> having a mutual TLSA validated TLS session from an IoT device to a
> server.
> 

Thanks.

> In addition, I was thinking there should be a 4th TLSA certificate
> usage, type 0 or 4, for TLSA to show cert that are revoked, if we know
> for sure the certificate is revoked then it should be presented and
> queried/answered as such,  an authoritative answer signed with DNSSEC
> to say certificate is revoked, not to be trusted anymore.

Picking nits, we already have four usages:

    - PKIX-TA(0)
    - PKIX-EE(1)
    - DANE-TA(2)
    - DANE-EE(3)

but more importantly, there is no need for publishing revocation via
DANE TLSA, since all the certificates that don't match are effectively
revoked.

Therefore, the robust way to revoke all known and even *unknown*
compromised certificates is to publish only PKIX-EE(1) or DANE-EE(3)
TLSA records matching the legitimate certificate of the service.

If the goal is to deal with a known compromised key (the only use case
handled by "revocation"), then exclusive use of PKIX-EE/DANE-EE records
need only extend past the original expiration of the would be revoked
certificate, after which time, one can return the service to using
PKIX-TA/DANE-TA if desired.

Better still, just always use DANE-EE/PKIX-EE and revocation is
something you never have to worry about.

DANE obviates certificate revocation, good riddance.

-- 
    Viktor.

---

From: Jacques Latour <[email-masked]>
Date: Tue, 15 Jun 2021 13:30:43 +0000

Top post: I think in the context of IoT Device Client Identity, the identity of an individual device can be revoked for other reasons than a compromise, for example if an IoT device is repurposed for a new use, then a new identity would be provisioned for the new purpose (new customer, new network), I think having a method of knowing that the old identity is revoked (say for 3 months) would be useful.  We would know for sure that the reprovisioning of a new identity to the IoT device didn't work.  Something like a CDS 0 0 0 for TLSA.

CLASSIFICATION:CONFIDENTIAL

-----Original Message-----
From: Danish <[email-masked]> On Behalf Of Viktor Dukhovni
Sent: June 14, 2021 11:35 AM
To: [email-masked]
Subject: [EXT] Re: [Danish] IoT Device Identification with TLSA via Danish

On Mon, Jun 14, 2021 at 02:40:38PM +0000, Jacques Latour wrote:

> https://github.com/CIRALabs/CIRA-Secure-IoT-Registry/blob/master/CIRA%
> 20-%20Challenges%20in%20DNSSEC%20IoT%20Registry%20-%20ICANN%202021-6-1
> 4.pdf

Thanks.

    - PKIX-TA(0)
    - PKIX-EE(1)
    - DANE-TA(2)
    - DANE-EE(3)

but more importantly, there is no need for publishing revocation via DANE TLSA, since all the certificates that don't match are effectively revoked.

Therefore, the robust way to revoke all known and even *unknown* compromised certificates is to publish only PKIX-EE(1) or DANE-EE(3) TLSA records matching the legitimate certificate of the service.

If the goal is to deal with a known compromised key (the only use case handled by "revocation"), then exclusive use of PKIX-EE/DANE-EE records need only extend past the original expiration of the would be revoked certificate, after which time, one can return the service to using PKIX-TA/DANE-TA if desired.

Better still, just always use DANE-EE/PKIX-EE and revocation is something you never have to worry about.

-- 
    Viktor.

--
Danish mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/danish

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Jun 2021 09:57:10 -0400

On Tue, Jun 15, 2021 at 01:30:43PM +0000, Jacques Latour wrote:

> Top post: I think in the context of IoT Device Client Identity, the
> identity of an individual device can be revoked for other reasons than
> a compromise, for example if an IoT device is repurposed for a new
> use, then a new identity would be provisioned for the new purpose (new
> customer, new network), I think having a method of knowing that the
> old identity is revoked (say for 3 months) would be useful.  We would
> know for sure that the reprovisioning of a new identity to the IoT
> device didn't work.  Something like a CDS 0 0 0 for TLSA.

This still does not make a case for revocation TLSA records.  These
would needlessly complicate existing implementations.  The current
design is that any matching TLSA record is sufficient for a valid
outcome, and unsupported (unusable) TLSA record types can be safely
ignored.

Adding revocation records breaks the semantics.  And, as I pointed
out, the revocation record is redundant.  Just publish "3 1 0" or
"3 1 1" and you've renounced *all* other keys, by specifying only
the valid key(s).

-- 
    Viktor.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jun 2021 14:38:25 -0400

Jacques Latour <[email-masked]> wrote:
    > a compromise, for example if an IoT device is repurposed for a new use,
    > then a new identity would be provisioned for the new purpose (new
    > customer, new network), I think having a method of knowing that the old
    > identity is revoked (say for 3 months) would be useful.  We would know
    > for sure that the reprovisioning of a new identity to the IoT device
    > didn't work.

A premise of DANISH is that the device comes with an identity, supplied by a manufacturer.
This is the part where the device does not need to go through an onboarding
process (to a private CA), but rather it's enough to configure the name of
the device into an authorization list.

If the device is repurposed, then it won't get a new name. (that would
require that it be onboarded with a name name, right?)
So, in order to repurpose a device, it needs to be removed from whatever
authorization list it was on, and then added to the new authorization list.
Revoking the certificate would keep the device from being able to be used in
the new purpose.

{I personally think that this is a negative of DANISH.
Maybe it's not a core aspect of it, but it seems like it to me.}

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Jun 2021 14:49:48 -0400

On Tue, Jun 15, 2021 at 02:38:25PM -0400, Michael Richardson wrote:

> A premise of DANISH is that the device comes with an identity,
> supplied by a manufacturer.  This is the part where the device does
> not need to go through an onboarding process (to a private CA), but
> rather it's enough to configure the name of the device into an
> authorization list.
> 

This sounds like a provisioning + de-provisioning lifecycle issue,
rather than an authentication issue.  DANE is concerned only with
authentication.  Questions of authorisation are out of scope for DANE
(and by extension the parts of DANISH that deal with validating
certificate chains, ...).

> So, in order to repurpose a device, it needs to be removed from
> whatever authorization list it was on, and then added to the new
> authorization list.

Definitely, and the new authorisation list is perhaps a problem
for an entirely new owner.

> Revoking the certificate would keep the device from being able to be
> used in the new purpose.

Certificate revocation is not the right mechanism for dealing with
authorisation changes.
key, and bind that 

> {I personally think that this is a negative of DANISH.  Maybe it's not
> a core aspect of it, but it seems like it to me.}

If the key is immutable for the lifetime of the device, and not
strongly protected against extraction by its previous owner, then
change of ownership potentially leaves the new owner unsure whether
the device is still "trustworthy" (assuming it was ever trustworthy
to begin with, ...walks away muttering something about supply chain
security under his breath...)

-- 
    Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 15 Jun 2021 15:23:44 -0400 (EDT)

> "3 1 1" and you've renounced *all* other keys, by specifying only

I do have to agree with Viktor here. If you drop this assumption and
publish revoked keys in TLSA, then you are basically mixing signals.
The TLSA record says "valid", but now you _still_ have to do PKIX
to determine if it is in fact not "invalid". This also kind of leads
to a security level that is the lowerst of the two systems combined.

Furthremo, it people start depending on revocation of certs inside
TLSA, it will forever intertwine DNSSEC and PKIX into the future,
and like Viktor already said, that would actually harm DNSSEC deployment
instead of making an easier migration path to it.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jun 2021 15:57:00 -0400

> security under his breath...)

Yes, that's the point.
The immutability for the lifetime of the device is a source of great power,
but also a problem.

We should consider if we can use either subcerts/delegated certificates here
in a useful way.
  https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/
  https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/

I have considered that using them would be appropriate when the IDevID is
stored at the far side of a really slow I2C/SPI bus into a TPM.  You don't want
to use it for "day to day" operations in that case.

---

From: Ash Wilson <[email-masked]>
Date: Tue, 15 Jun 2021 13:06:12 -0700

FWIW, I'm a fan of immutable DNS names and rotating certs. If the device
can rotate its own certificate with the CA, then an automation component
between the CA and DNS server can manage the rotation for DANE via TLSA
records.

It only gets easier over time to guess private keys. Being able to rotate
them would be a big advantage over the lifetime recommendation in IEEE
802.1AR for device certs.

-- 

*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: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Jun 2021 16:36:20 -0400

> between the CA and DNS server can manage the rotation for DANE via TLSA

This sounds reasonable, of course there needs to be some way to prevent
the previous owner from also being able to rotate the device key based
on knowledge of the previous key.

Which means, that key rollover locks the previous key out of future
device metadata updates.

-- 
    Viktor.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jun 2021 17:33:31 -0400

> 802.1AR for device certs.

I agree.  If we can safely rotate private keys that are otherwise buried deep in a
device, then great, that improves things.  But, we shouldn't design on the
assumption that this is the only way.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Jacques Latour <[email-masked]>
Date: Wed, 16 Jun 2021 13:32:36 +0000

Viktor,

> Adding revocation records breaks the semantics.  

I'm with you here.

>And, as I pointed out, the revocation record is redundant.  Just publish "3 1 0" or
> "3 1 1" and you've renounced *all* other keys, by specifying only the valid key(s).

Two scenarios, first, if the IoT device has a new identity then we publish a new TLSA - done, old key are to be untrusted. This works. All good.

Second scenario for IoT device that can have their identity reprovisioned, if an IoT device is compromised/not to be trusted/not to be used for whatever reasons, a NSEC record does not represent that status, but could we put a 0 (?)  value 4th TLSA Certificate Association Data field, the presence of the TLSA would show it exists, the null cert value would show don't use, but it exists, so the logic on the server could be different to figure out what do to with that IoT device, instead of a nonexistence record.

Jack

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 Jun 2021 10:22:09 -0400

> On 16 Jun 2021, at 9:32 am, Jacques Latour <[email-masked]> wrote:
> 
> An NSEC record does not represent that status,

If DANE is a required (not opportunistic) mechanism for the use-case,
then NSEC does in fact indicate that the DNS name is no longer valid
for authentication, but otherwise ...

> but could we put a 0 (?)  value 4th TLSA Certificate Association Data field,

A SHA-256 hash that is all zero (all 32 byhtes or 64 hex nibbles) can
be used as an effective way to disclaim all keys.

   _foo.name.example IN TLSA 3 1 1 0000000000000000000000000000000000000000000000000000000000000000

> so the logic on the server could be different to figure out what do to with that IoT device, instead of a nonexistence record.

The device would only authenticate if its public key has a SHA2-256 hash
that is all zero.  It is not publicly known how to find such a 2nd
pre-image for SHA2-256, and believed to be out of reach of even nation
state security agencies.

-- 
	Viktor.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 19 Jun 2021 12:51:15 +0000

Hi Jacques,

Thanks for sharing your slides. Since the slides are not meant to be self-explanatory I have a question for you: What is an IoT registry for you?
(You mention the term on slide 2 and it seems to be core to your presentation.)

Ciao
Hannes

From: Danish <[email-masked]> On Behalf Of Jacques Latour
Sent: Monday, June 14, 2021 4:41 PM
To: [email-masked]
Subject: [Danish] IoT Device Identification with TLSA via Danish

Hi,

Jacques

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 19 Jun 2021 14:01:49 +0000

Hi Michael, Hi Jacques,

I found this email thread and was wondering about one aspect in the context of authorization lists.

Where are these authorization lists stored and who creates them?
In what you use cases do you need to configure these authorization lists?

Ciao
Hannes

PS: I would avoid to use the term "identity" because here we are only talking about an identifier. Identity has so much baggage, which is probably not useful in this context.

-----Original Message-----
From: Danish <[email-masked]> On Behalf Of Michael Richardson
Sent: Tuesday, June 15, 2021 8:38 PM
To: Jacques Latour <[email-masked]>; [email-masked]
Subject: Re: [Danish] [EXT] Re: IoT Device Identification with TLSA via Danish

A premise of DANISH is that the device comes with an identity, supplied by a manufacturer.
This is the part where the device does not need to go through an onboarding process (to a private CA), but rather it's enough to configure the name of the device into an authorization list.

If the device is repurposed, then it won't get a new name. (that would require that it be onboarded with a name name, right?) So, in order to repurpose a device, it needs to be removed from whatever authorization list it was on, and then added to the new authorization list.
Revoking the certificate would keep the device from being able to be used in the new purpose.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Jun 2021 16:25:16 -0400

> In what you use cases do you need to configure these authorization lists?

I can't speak for Ash and/or Shumon's projects where some of these
requirements came out of.   I've suggested that it would be great to know
more about some of the experiences that have driven some of their
requirements.

I think that the IoT application operator creates the lists.

I imagine that either an installer scans some (QR?) code on the
sensor/actuator, or perhaps they identify the device to the operations center
by interacting with it.  Somewhat like a brain surgeon poking neurons and
observing what things it moves, or having the person report what they sense.

Or like buzzing out wires: https://en.wikipedia.org/wiki/Signal_tracer

---

From: Jacques Latour <[email-masked]>
Date: Mon, 21 Jun 2021 14:50:05 +0000

Hi Hannes,

Yes, in my presentation on very first slide I said "we presented the IoT Registry many times in the past at many venues", the IoT Registry for us is an identity management system for mobile GMSA IoT SAFE enabled IoT devices. It's the gateway between the mobile network operators and the cloud/ASPs.

  *   See https://github.com/CIRALabs/CIRA-Secure-IoT-Registry/blob/38c3128651fbfcf8a0b5bd40523cd7dc12a5bc70/CIRA%20-%202020-01-22%20ICS%20Symposium.pdf

In short, in the IoT Registry we track the identity of the IoT device (public key or certificate) to a unique eSIM ID via IoT SAFE.

In this context, I'm a big fan of making available in the DNS w/DNSSEC the individual IoT device identity via the proposed DANISH mechanisms.

Jacques

CLASSIFICATION:CONFIDENTIAL
From: Hannes Tschofenig <[email-masked]>
Sent: June 19, 2021 8:51 AM
To: Jacques Latour <[email-masked]>; [email-masked]
Subject: [EXT] RE: IoT Device Identification with TLSA via Danish

Hi Jacques,

Ciao
Hannes

From: Danish <[email-masked]<mailto:[email-masked]>> On Behalf Of Jacques Latour
Sent: Monday, June 14, 2021 4:41 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Danish] IoT Device Identification with TLSA via Danish

Hi,

Jacques