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

[Michael Richardson <[e-mail]>]

<#secure method=pgpmime mode=sign>

Hi Ash,
   I AM NOT A PKIX FAN.
   I hate it, BUT:

Ash Wilson <ash.wilson=[e-mail]> wrote:
    > 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.

Could you explain a bit more about "operate my own CA".
What infrastructure are you willing to operate?

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

But, which certificates do you use? The IDevID ones?
If so, do you just have a database which each EE certificate pinned?

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

How is this different than providing a database of EE or public keys?

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

I dunno, it feels like you are willing to jump through a lot of hoops to
avoid running a CA.  CAs are only hard if you are public and have CPS.

    >   Message/object security use case: I want my edge nodes to forward

This seems moot.  Either way, you can use object security if you can track
the signature to an identity.

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