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

[Toerless Eckert <[e-mail]>]

> > On 16 Nov 2020, at 20:13, Ash Wilson <ash.wilson=[e-mail]> 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.
> 
> 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-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.

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 dependencies.  With OCSP (even with stapling) the situation might prove a little different.  This is worth discussion.

Yes, lot of devils in details.

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

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.

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

Time permitting, sure.

Cheers
    Toerless

> Eliot