Re: [Secdispatch] [saag] The Mathematical Mesh

Nico Williams <> Tue, 23 April 2019 03:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 412CC1202E9; Mon, 22 Apr 2019 20:49:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tw8k-3TCbxIJ; Mon, 22 Apr 2019 20:49:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 08F081200C3; Mon, 22 Apr 2019 20:49:24 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|
Received: from (localhost []) by (Postfix) with ESMTP id 3476E3E4CA4; Tue, 23 Apr 2019 03:49:23 +0000 (UTC)
Received: from (unknown []) (Authenticated sender: dreamhost) by (Postfix) with ESMTPA id B33993E52FC; Tue, 23 Apr 2019 03:49:22 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.17.2); Tue, 23 Apr 2019 03:49:23 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|
X-MailChannels-Auth-Id: dreamhost
X-Scare-Juvenile: 17cc082d7fd0fc5f_1555991363017_3952312522
X-MC-Loop-Signature: 1555991363017:3502328466
X-MC-Ingress-Time: 1555991363016
Received: from (localhost []) by (Postfix) with ESMTP id 5AAF382663; Mon, 22 Apr 2019 20:49:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=BrWw6SydtVwDsp hO7rCO2V/JhVc=; b=T7BDc1FhAYKnSa5kBxhHbGNaRw/v3+qTrdRwCYDr37PX2e 9rG1t3PCCQzP2mwBz0FwrhiL2FVB9dFh9U//YziPFUxHPzvCYiUTUf923Uqw/jMr Q1ItMQ01yevPgWmgXCH9TbEy2pMH2mxM8yMGaqOhY7q1A5uP6IDPD5GM60iMs=
Received: from localhost (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 15DAB82661; Mon, 22 Apr 2019 20:49:20 -0700 (PDT)
Date: Mon, 22 Apr 2019 22:49:18 -0500
X-DH-BACKEND: pdx1-sub0-mail-a18
From: Nico Williams <>
To: Phillip Hallam-Baker <>
Message-ID: <20190423034917.GF3137@localhost>
References: <> <20190422190302.GA3137@localhost> <> <20190422203812.GB3137@localhost> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgdeihecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
Archived-At: <>
Subject: Re: [Secdispatch] [saag] The Mathematical Mesh
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Apr 2019 03:49:27 -0000

On Mon, Apr 22, 2019 at 11:17:07PM -0400, Phillip Hallam-Baker wrote:
>                    [...]. One distinction I do feel very strongly on is
> that the configuration of trust relationships between devices belonging to
> the same entity is a completely different issue to the problem of trust
> between entities.

So much so that it's even separable from the rest.

When it comes to one's own devices (for some value of "own"), the
introducer problem is trivially solved: one is the introduced, and
assuming physical access, the rest is trivial.

Indeed, smartphone vendors have even solved that -- within their walled
gardens anyways.

Getting an interoperable protocol for device key management widely
implemented would be a real coup.

> > But I do feel that the device management part is separable, even though
> > it's certainly critical for the UX.
> I have no objections to an a-la-carte approach. The device management part
> is certainly the core here.

I'm not asking for it to be separated, just noting that it is separable.

Again, I'm looking for a pithy description of the proposal.  It's now
"all ove the above as to trust" + "open device key management".
Anything else?

> > > Right now, I am doing everything in JSON and the Mesh Assertion
> > > infrastructure. It is pretty obvious that some of this is SAML territory.
> > > But where should the boundary be and should we make use of the XML SAML
> > > binding or switch it to a JSON encoding? I don't know what the right
> > > decision is there or have time to think about it.
> >
> > It's always tempting to start from scratch...  But it's already been
> > done via OAuth/JWT.  Don't feel bad for not using SAML/XML.  Just make
> > the right choice.
> Naturally and this is one of the reasons I have steered clear of the
> inter-trust problem because it has been the part of the problem we like to
> beat on most.

On the other hand, to follow an all-of-the-above path means
interoperating with existing protocols wherever that helps.

For example, there's no need for a replacement for PGP or S/MIME.  What
is needed is a way to simplify introductions and key exchange, to get it
down to scanning a QR code and pressing a button.  Ditto TOFU (though
that's trickier, naturally).  Ditto WebPKI.

I've this idea that DANE stapling in TLS could be used to provide not
just server authentication to clients, but also user authentication to
servers, using client EE certificates with rfc822Name SANs and DANE to
authenticate the domainname of a client certificate's rfc822Name SAN(s).

(Many don't trust the DNSSEC root any more than others trust WebPKI, but
for most users, anything is better than nothing.)

The varying levels of trust will surely complicate the UI somewhat.  At
least power users will want to be able to see some indication of trust
strength / how an introduction happened.