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

[Eliot Lear <[e-mail]>]

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=[e-mail]> 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.
> 
> 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 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.

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

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