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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 03 December 2020 18:44 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 42F9A3A08B1 for <iot-onboarding@ietfa.amsl.com>; Thu, 3 Dec 2020 10:44:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 10fmceEHAE3Y for <iot-onboarding@ietfa.amsl.com>; Thu, 3 Dec 2020 10:43:58 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C2A3A083B for <iot-onboarding@ietf.org>; Thu, 3 Dec 2020 10:43:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8FE0C389CD; Thu, 3 Dec 2020 13:45:49 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FnsDai4VPgXO; Thu, 3 Dec 2020 13:45:48 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B2CF389CC; Thu, 3 Dec 2020 13:45:48 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6DFF01FB; Thu, 3 Dec 2020 13:43:55 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ash Wilson <ash.wilson=40valimail.com@dmarc.ietf.org>
cc: "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, Shumon Huque <shuque@gmail.com>
In-Reply-To: <CAEfM=vTJOHbvomtZ0NSv2GRumycA+iOJaA2oeAMtFQWN4pabUw@mail.gmail.com>
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>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 03 Dec 2020 13:43:55 -0500
Message-ID: <2085.1607021035@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/FnexI3qHg1BMK0Z75Dtbg4vd0hY>
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: Thu, 03 Dec 2020 18:44:08 -0000

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.

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.

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