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

[Ash Wilson <[e-mail]>]

On Wed, Dec 2, 2020 at 5:28 PM Michael Richardson <[e-mail]>
wrote:

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

As an application owner, my priority is operating only what's required to
securely and reliably deliver my application's functionality. If I can get
broadly useful device identity from the device supplier, that represents a
reduction in the footprint of the application I'm responsible for
maintaining.

If the supplier ships devices with certificates or raw public keys already
in DNS, I may not need to re-key to my own PKI. This makes a handful of
assumptions, including that keys are provisioned in an appropriately secure
manner (which
https://tools.ietf.org/html/draft-richardson-t2trg-idevid-considerations-01 can
help with).

This process could require the supplier to manage the DNS namespace for the
devices they ship with this type of identity. Alternatively, I could give
the supplier a list of names I would like to have assigned to devices, and
then receive an archive of all the device certificates to bulk-upload into
a DNS zone which I maintain.

I can run my own CA if I need to... But the need to do so diminishes if
DANE allows me to avoid name collisions and to perform mutual auth without
having to distribute CA certificates.


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

This depends on the configuration of the TLSA record. If the certificate
usage is 3 (DANE-EE), then the certificate or public key is validated
against the device's TLSA record(s) and PKIX validation is not required.
In this use case, the RADIUS server just needs a list of permitted
identities. If the supplicant can prove possession of a private key
associated with a DANE identity on the RADIUS server's 'allow' list, the
device is allowed onto the network. This can be an IDevID or LDevID
certificate, as long as it has a name in DNS.

The database which associates names to public keys is DNS, and the RADIUS
server only needs a list of permitted DNS names.


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

This actually is providing a database of public keys, but the database is
DNS and identities can be maintained by whoever the application owner
trusts to do so (mfr, implementer, etc...). The same database (DNS) can be
used to support authenticating network access as well as message signature
verification.


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

I agree that CAs don't have to be difficult to operate. There are a number
of providers who have great user interfaces and provide useful APIs and
integrations. As an application owner, I want to focus on the core
functionality of my application, and if I can purchase/lease devices with
immediately useful identities, then I don't need to maintain a CA component
(as-a-service or otherwise) as a part of my application footprint.


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

This is all about simplifying the process of discovering public keys. If
the message bears the sending entity's DANE/DNS name, the recipient can use
DNS to retrieve the public key.
This improves:
* Network bandwidth consumption: No need for the message sender to also
transmit a certificate.
* Removal of implied trust: No need to base trust for message integrity and
attribution on middleware if the message can be independently verified.
* Systems integration: You don't need to integrate with a proprietary API
to retrieve certificates for message authentication. Rather, DNS can become
the discovery API for every CA that wishes to participate.


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

-- 

*Ash Wilson* | Technical Director
*e:* [e-mail]


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.