Re: [saag] post-X509 cryptographic identities

Nico Williams <nico@cryptonector.com> Tue, 11 February 2020 17:45 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42932120981 for <saag@ietfa.amsl.com>; Tue, 11 Feb 2020 09:45:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 D0IataPDV1KJ for <saag@ietfa.amsl.com>; Tue, 11 Feb 2020 09:45:55 -0800 (PST)
Received: from bird.elm.relay.mailchannels.net (bird.elm.relay.mailchannels.net [23.83.212.17]) (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 253D5120949 for <saag@ietf.org>; Tue, 11 Feb 2020 09:45:55 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6226421295; Tue, 11 Feb 2020 17:45:54 +0000 (UTC)
Received: from pdx1-sub0-mail-a89.g.dreamhost.com (100-96-13-15.trex.outbound.svc.cluster.local [100.96.13.15]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 8E30720EE3; Tue, 11 Feb 2020 17:45:53 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a89.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Tue, 11 Feb 2020 17:45:54 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Madly-Unite: 01f2165d13655c95_1581443154022_2348748157
X-MC-Loop-Signature: 1581443154022:1796781371
X-MC-Ingress-Time: 1581443154022
Received: from pdx1-sub0-mail-a89.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTP id 4D41C7EEE6; Tue, 11 Feb 2020 09:45:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=kzR/wOewX7VXql4t3ylR10GyiOU=; b=T9b5QrcAPN8 8U3wFn/FsvYtKODFST0y5ubflsdQfanIFWpLM3oiPao7m/FI6PzVBDTtCa7NQrKO /RBlWbR71E7bG466z7VZzJnMGxhDoRb8+vtWtoQbO/5p7Iue3bt9UgMdYynOngQ3 RzIPy3BD8db0sP74+zLaWhKhOoQPVCLg=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 39C8C7E60A; Tue, 11 Feb 2020 09:45:46 -0800 (PST)
Date: Tue, 11 Feb 2020 11:45:44 -0600
X-DH-BACKEND: pdx1-sub0-mail-a89
From: Nico Williams <nico@cryptonector.com>
To: Henry Story <henry.story@gmail.com>
Cc: saag@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>
Message-ID: <20200211174543.GL18021@localhost>
References: <2C5DFA70-AD0E-4139-B28E-2D4EDB6E5409@sinodun.com> <46BDE9EB-6306-4194-AFFA-7E9E6604765F@sinodun.com> <825b8c8e-7ee9-9276-d09e-9c006acf3804@ericsson.com> <CABcZeBOzJ2MRS8deZqN+e-o9tFDwgSrYK3_hmV-0pfO+L9oaVw@mail.gmail.com> <53c87d6b-cad1-3a80-291d-e2a896705da5@ericsson.com> <CABcZeBNJWmFTV==6sa0qnAPyRr4=6OiCacchzobE=RozHnqPdg@mail.gmail.com> <7901248e-c7dd-8a12-65df-f40415fde5e2@cs.tcd.ie> <26497.1581418516@dooku> <20200211165720.GH18021@localhost> <DF09BF39-20E3-4BDE-B1E2-8C84864DF0F7@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <DF09BF39-20E3-4BDE-B1E2-8C84864DF0F7@gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrieefgdelkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucffohhmrghinhepmhgvughiuhhmrdgtohhmpdgtohdqohhpvghrrghtihhnghdrshihshhtvghmshenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/aOCKh510GNgJIBcdhjQOY4TQrbs>
Subject: Re: [saag] post-X509 cryptographic identities
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Feb 2020 17:45:58 -0000

On Tue, Feb 11, 2020 at 06:32:42PM +0100, Henry Story wrote:
>   I think that if one is going to rethink security and identity
> on the internet one needs to revisit some deep assumptions about
> what web site identities are and their relation to legal spaces.
> 
> DNSSEC DANE can be an answer to identity of web sites and it can be
> politically acceptable if DNSSEC moves towards being decentralized on
> a national basis the way it was designed to be. But it cannot deal
> with the legal aspect of identity which requires deeper tie in to
> legal systems.

Anyone can mirror and sign their own ., observing and controlling key
rotations for TLDs, and avoiding active (MITM) attacks by anyone
possessing the keys to the root.

There's your decentralization.

Q: Why even want decentralization?
A: For protection from active attacks by roots.

Better than decentralization, let's discuss protection from active
attacks by privileged entities with access to root/TLD private keys:

 - Use QName minimization to make life much harder for any would-be
   privlieged entity to mount active attacks.

 - Add CT-like after-the-fact auditing of past resolutions, and you have
   all the active attack protection you can expect from a rooted PKI.

   One does not even need CT to do this to some degree and get some
   protection, though adding CT for DNSSEC would help.

> The same is true of X509. It can also work to verify identifiers for
> web sites, and Let’s encrypt does a great job for that. 

WebPKI can never have a root.  WebPKI is already decentralized.

The problem with WebPKI is not lack of a root nor centralization, but
lack of name constraints.

DNSSEC has name constraints fully built-in to the system.

> I explain what is is good and what the limitations are in
> "Stopping (https) phishing"
> https://medium.com/cybersoton/stopping-https-phishing-42226ca9e7d9

Phishing is a whole different and separable issue.  The fundamental
problem with phishing is that humans too-easily fall for scams, and no
authentication technology can stop this.

> But one has to think much bigger and from an epistemological point
> of view. That is one has to consider what it is that the user of
> a browser can learn from the information given to him.

See above.  Humans are stupid and fall for scams too easily.  Technology
cannot provide a complete answer to that.

> Currently one learns nearly nothing from an X509 certificate. Nothing
> that is interesting enough and useful enough to a user, that they
> would feel like looking there. And nothing that really helps establish
> trust in an international environment. That requires one to tie these
> into rich data provided by legal systems tied into a ”Web of Nations” 
> https://co-operating.systems/2019/07/29/Web_of_Nations.proposal.pdf

See above commentary about name constraints.

Nico
--