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

[Ash Wilson <[e-mail]>]

Hi there,
Reviving this thread (and cross-posting to iotops) to tie in the BoF on
Friday, on this topic.

The DANISH BoF is scheduled on Friday at 13:00 GMT+1 (
https://datatracker.ietf.org/wg/danish/meetings/)

In a general sense, this BoF proposes the use of DANE for TLS client
identity, as well as certificate discovery for object security
(signing/encryption) use cases.

We will be discussing three drafts, together with a conversation on the
problem space and the use cases that may benefit from this approach.

The first two were published ahead of scheduling the BoF, and the third was
published early this week:
https://tools.ietf.org/html/draft-huque-dane-client-cert-05
https://tools.ietf.org/html/draft-huque-tls-dane-clientid-04
https://datatracker.ietf.org/doc/draft-wilson-dane-pkix-cd

Hope to see you there!

-Ash

On Fri, Dec 4, 2020 at 11:28 AM Ash Wilson <[e-mail]> wrote:

>
>
> On Thu, Dec 3, 2020 at 1:44 PM Michael Richardson <[e-mail]>
> wrote:
>
>>
>> Hi, I don't want to religate the email again.
>> I accept pretty much all your claims, except that:
>>
>> > 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.
>>
>> This seems to imply that running a private CA is at least an order of
>> magnitude harder than managing a DNS zone containing TLSA records,
>> and which is probably DNSSEC signed.
>>
>> It is unclear to that your application needs either: it seems like it just
>> needs a database of public keys which are authorized, and you already
>> seem to
>> assume the existence of a radius server with a database backend.
>> I think that radius servers can be as complex as signed DNS zones, or
>> simple private CAs.
>>
>> I'm sorry to be obtuse here: others will ask the question.
>>
>
> I really appreciate your feedback. The more questions we answer now, the
> fewer we will need to answer later on.
> I agree- RADIUS can be quite complicated. The hope is that if the CA and
> DNS are operated by the manufacturer/supplier, the amount of configuration
> complexity required for RADIUS or other EAP-TLS authentication server (if
> operated by the application owner or network manager) might be reduced.
>
> We can't eliminate all complexity, but there may be an opportunity to
> simplify and shift some complexity up the supply chain and away from the
> application owner. By allowing the supplier to take on some of the
> responsibility for identity (via PKI and DNS), the application owner may
> more easily (or less expensively) use strong device identity. I'm making
> the assumptions that the application owner (1) has influence on security
> aspects of the application design, (2) wants to build a secure
> application, and (3) wants to minimize complexity in implementation. The
> hope is that reducing the application owner's complexity (authentication
> infrastructure) and expense (human labor) for PKI-based authentication will
> encourage broader adoption.
>
>
>> It sounds like your application is primarily a mp2p data flow
>> (device->cloud).
>> I'm finding it difficult to see why a DNS zone full of TLSA records is
>> even
>> required.
>
>
> The simplification gains are definitely greater as the application
> becomes more complex/decoupled/m2m.
> If the communication pattern is directly device-to-cloud, then it may make
> more sense to just work with traditional PKI, private CA, etc... This is
> certainly not a silver bullet for all IoT authentication needs :-)
>
> There's a point of complexity where it makes more sense to take the DANE
> approach, and I suspect that it will be driven by a few aspects:
> * How many device suppliers will my application have?
> * Can my suppliers ship devices with identities already in DNS?
> * Does my application make use of messaging middleware, like MQTT brokers
> and message queues?
>   * How much do I trust the middleware to resist unauthorized
> access/behavior? (level of comfort with implied trust)
>   * What is the potential impact of message sender impersonation in my
> application?
>   * Should I be signing messages to help prevent sending device
> impersonation?
>
>
>>
> If we get into e2e  (m2m) data flows, then the ability for one device to
>> validate another device without directly communicating with a third party
>> is
>> a win.  For that, a private CA or a DNS zone of TLSA keys, particularly,
>> as
>> you say, that DNSSEC record cache proposal, makes perfect sense to me.
>>
>> My proposal going forward:
>>    section 2 of draft-huque-dane-client-cert
>>
>> needs to expand to a couple of pages.
>>
>> The SMTP use case should probably get it's own section; perhaps its own
>> document actually.
>>
>> I think that:
>>        TLS Extension for DANE Client Identity
>>            draft-huque-tls-dane-clientid-03
>>
>> is clear and simple, and once we figure out where huque-dane-client-cert
>> goes, then I think that this document should just be referred to the TLS
>> WG.
>> The previous document should then provide adequate explanation of the
>> context.
>>
>> --
>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting
>> )
>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>
>>
>
> --
>
> *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.
>


-- 

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