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

Ash Wilson <ash.wilson@valimail.com> Fri, 04 December 2020 19:28 UTC

Return-Path: <ash.wilson@valimail.com>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F10E3A0EE5 for <iot-onboarding@ietfa.amsl.com>; Fri, 4 Dec 2020 11:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0pt9ZTzAiRJ for <iot-onboarding@ietfa.amsl.com>; Fri, 4 Dec 2020 11:28:43 -0800 (PST)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D9E3A0EE3 for <iot-onboarding@ietf.org>; Fri, 4 Dec 2020 11:28:42 -0800 (PST)
Received: by mail-qk1-x72a.google.com with SMTP id b144so6466588qkc.13 for <iot-onboarding@ietf.org>; Fri, 04 Dec 2020 11:28:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=49Wc0eKKaFlUOqHIzZnHDg6nMgl/3cKHt0P0C6QbG90=; b=YS57SYS4NUVZAvhaRpG+IdXihc5g8XbVuUEPJsSUUn3ON0PPBmHlHFvGflPn7fwp4O 90syS8ymxX8MRKtuRIPC4EtyoFT/a2IBTWjY9EftXwnjmEL49yX0MBkCdykFfmp/GPCO bUiIKf5qJkcilFtdxGeoFJwggriAkMYuk1AiVprfD7o4PmwVwUrl5RCdCNKyGQeT/feX CPNK/9PXx5WlIsbNKR8Imz4kmN2gaDK7oNFelPphSFVYVhr5gc/b4Sjz7EWT62bWX3DM 3R54eER2jFg9efg94Hg4LT6rMm2gcSZ+RjwgNjJAI9BWBqMdxuON5IvU80epZ8k0eign MH8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=49Wc0eKKaFlUOqHIzZnHDg6nMgl/3cKHt0P0C6QbG90=; b=aOu9fMgaAp9CoMoq5qUOitla5fNJEP3iMoxTgLQ8A4hyK/2CY+Vv2dlrh+KbRR6sjW fHfmVROMAJUNK8jyqcfA1xK6t7kW4PWCGxYFMVvG6zItbb5c5gAjdzI/bvm+/r+B7Hz5 NfjKO4JyIOhMM56h7FQUS+XvwV8n0oomf9W4bz3oqfGrckQf+U0iA7j+GJxb6iwTRxcZ b6FDH2GjiiDzQYeUa+/sXnm9BkmG4ou+++otzcZyFDwrn5ga7gBEJt6NkjHFMnsQebyc yBRnyQnhN8tNjZptYog6TMcyZjuWzdabu+SJHKEPr39QehBg4c+UBit4QXw28zd9E/uL jVZA==
X-Gm-Message-State: AOAM530vx6WVBm4Ca9KV/AZN3BznKcx1sPWItdVt/gCdZFemirjKu/26 Od0IP8E7iCIfitltKQfhXFYV5wxxZSUib4g4tacHPw==
X-Google-Smtp-Source: ABdhPJwDO3kIWlpI5XruEfKmBMtIfqSwqnETRhYdiJG+qWSFgG4x97Z4FmTsszFJc1rLg/V4kHW/ZV+Z00cGjDZoxRI=
X-Received: by 2002:a37:6f07:: with SMTP id k7mr10990150qkc.423.1607110121704; Fri, 04 Dec 2020 11:28:41 -0800 (PST)
MIME-Version: 1.0
References: <2786E31F-2A4F-4901-8ECC-7AEF4B4D81E2@cisco.com> <b178d5066d6b4371a59ffe59bb6d6447@huawei.com> <CAHPuVdXo1o0d_WzLqTZ5s9+JNG=3kbNdTO1BrS7BdEBDd2F1Lw@mail.gmail.com> <CAEfM=vRotGf-SuYz8PKNop8zdCCA_-x+3xU81rMS6Le6EUOOFw@mail.gmail.com> <2FE1E13B-E313-43F9-932E-6682DF72E18D@cisco.com> <20201117074330.GP39343@faui48f.informatik.uni-erlangen.de> <CAEfM=vTDPi6fQXR+EQ7jW04RsyZQRQXHw3R-fH+QiC70JKSZaA@mail.gmail.com> <692795.1606948121@dooku> <CAEfM=vTJOHbvomtZ0NSv2GRumycA+iOJaA2oeAMtFQWN4pabUw@mail.gmail.com> <2085.1607021035@localhost>
In-Reply-To: <2085.1607021035@localhost>
From: Ash Wilson <ash.wilson@valimail.com>
Date: Fri, 04 Dec 2020 14:28:30 -0500
Message-ID: <CAEfM=vT_SwNW_1s8Xg4=X0QazLqvEkjV7N01FuuTh-LGwjao9Q@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, Shumon Huque <shuque@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000eb615c05b5a87bef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/WBgIJARePV25de19TTiS9xnbmCc>
Subject: Re: [Iot-onboarding] [Secdispatch] DANE IOT proposed outcome
X-BeenThere: iot-onboarding@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <iot-onboarding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-onboarding/>
List-Post: <mailto:iot-onboarding@ietf.org>
List-Help: <mailto:iot-onboarding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2020 19:28:45 -0000

On Thu, Dec 3, 2020 at 1:44 PM Michael Richardson <mcr+ietf@sandelman.ca>
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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>

-- 

*Ash Wilson* | Technical Director
*e:* ash.wilson@valimail.com


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.