Re: [Danish] Proposed WG Charter

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 15 June 2021 00:11 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: danish@ietfa.amsl.com
Delivered-To: danish@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC163A14B9 for <danish@ietfa.amsl.com>; Mon, 14 Jun 2021 17:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 lamvX0RScGkS for <danish@ietfa.amsl.com>; Mon, 14 Jun 2021 17:11:01 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757B73A14B8 for <danish@ietf.org>; Mon, 14 Jun 2021 17:11:01 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 420D2C551D; Mon, 14 Jun 2021 20:11:00 -0400 (EDT)
Date: Mon, 14 Jun 2021 20:11:00 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: danish@ietf.org
Message-ID: <YMfwFIifWntDj8Hn@straasha.imrryr.org>
Reply-To: danish@ietf.org
References: <YMZwG/l/pne2tHJF@straasha.imrryr.org> <A7723DDA-3B78-46AD-9449-B6DF7F211706@nohats.ca> <CAEfM=vSd7CuK58W=eX86GYaxKKBfOs8z1mnQQVXnrXf9x-co0g@mail.gmail.com> <CAEfM=vQ=y1qJsKq8r2G87P5SKUjJ+rsDzN5DFHBj7xWSeNxn0w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAEfM=vQ=y1qJsKq8r2G87P5SKUjJ+rsDzN5DFHBj7xWSeNxn0w@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/danish/D33-JxvC3la9dC6rXtvaUWFTtGg>
Subject: Re: [Danish] Proposed WG Charter
X-BeenThere: danish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <danish.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/danish>, <mailto:danish-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/danish/>
List-Post: <mailto:danish@ietf.org>
List-Help: <mailto:danish-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/danish>, <mailto:danish-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jun 2021 00:11:03 -0000

On Mon, Jun 14, 2021 at 02:13:10PM -0700, Ash Wilson wrote:

> Very often, mobile data used for IoT ends up going into a message broker
> or message queueing system, and the central application subscribes or
> otherwise consumes information from the messaging middleware. Without some
> sort of verifiable sender identity attached to the message itself, the
> identity of the sender and the integrity of the message is assumed based on
> the integrity of all middleware involved in passing messages. If we include
> the sender's DNS name in the message and protect it with a signature, then
> it may be verified by the central application, independent of the transport
> over which it arrives.

The encapsulation is then basically CMS I guess.  Which supports
attaching a signature and the signer's certificate chain to a message
(as well as encrypting the message to the recipient(s)).

> Consider that if a messaging middleware platform is trusted by
> multiple sophisticated smart cities applications, and none of those
> applications implement message authentication, the messaging
> middleware platform itself becomes an attractive target for a
> well-resourced adversary. Simply signing the messages passing through
> the system removes the pressure on the broker to ensure integrity, and
> reduces the value of a compromised broker.

And I guess the proposal on the table is to use DNS as the identity
database for clients, with TLSA records enabling the use of enterprise,
or vendor CAs client onboarding.

If the verifiers are then infrastructure services, they're more than
capable of running a validating resolver, and sites sophisticated enough
to operate a private CA are more than capable of signing their doain.

Working around DNSSEC in this design seems rather more complex than
just using it.

-- 
    Viktor.