Re: [saag] post-X509 cryptographic identities

Henry Story <henry.story@gmail.com> Tue, 11 February 2020 18:05 UTC

Return-Path: <henry.story@gmail.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 242221209C7 for <saag@ietfa.amsl.com>; Tue, 11 Feb 2020 10:05:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 96XcDHko3ZRw for <saag@ietfa.amsl.com>; Tue, 11 Feb 2020 10:05:07 -0800 (PST)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 0FF401209C9 for <saag@ietf.org>; Tue, 11 Feb 2020 10:05:04 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id c84so4753395wme.4 for <saag@ietf.org>; Tue, 11 Feb 2020 10:05:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4zpZzypfmrMgjNP5VMiH69LkNAb5GyIDac3621+KiDQ=; b=UaybaeGqWafKetB50ouZ6Bgwll7S38ekl3ycAV64v069wM/0xZ/j9Riq+Vy5iEdpq6 fXbU7Jma7XiJuxViV1cwVILJduh2Ltp12Feoxh7WrBi2UZ4UHyJqst5cFl8piKeIe9G9 WJZAeVX/v04Qisda3t9s8uTXbvNAv+DyUzeboo+T3bdshpFdqgNDzZg/aFVEKCrv2fAO ibTVSoCwETefifKnfbemBMC7WRTs7xb/IkT3Qa+njINUecCMiF+FC3xG7D4utiovSf8s oRwxPj1PUfAoUx3tGiE+D+og3HAkV4zgqmWxxjmQ1y7nJqLzaNmFgTi705pbfgPMnjOh AKUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4zpZzypfmrMgjNP5VMiH69LkNAb5GyIDac3621+KiDQ=; b=gw7NDIYEmMVaISdryu5RI9h4wOmKo5zjJoOzw7qA1lrYB02K9rG/jJO3Pd/zPUAHV5 7szAYN3dqs1KRBL/fVFh3d8Ti5I+eAGMhSRnXvhOes0NLCTwqctu2oYqsepHFmherJKH 3iohAPHulllCemSxndtd8gWe8rf1/9uXXPnhBCVMUnRRMlDiz1YkL/n1x9RF9m7C5RzN 6wgoWkVy9MEGacdnrWuX1OVP5oKUQVnBW07FIwrUJL7L0wP92ziqZJ3mKB/YZ+LhiXR/ Uejl74r0QkcU/zV9GstdZw/yMaygauVH0vOYJUXMGHnhuMZRIo4AXeJ9V6Lc/rQzP6SK TFFw==
X-Gm-Message-State: APjAAAXaXs+LghZ02RhvawUXOgmtT3C/lDM5el4SFagQL9xWnvOCaXCA XCIyRQz0+apyB3/z/wWD26D9NhFhrx4=
X-Google-Smtp-Source: APXvYqyM0CMh03gDijB6SQp2EwzxfAGNNSRyDQoxgT0CDgl3Vo782/9xjRuVnP/gz76gf2GmnVWrtA==
X-Received: by 2002:a1c:cc11:: with SMTP id h17mr6697510wmb.19.1581444303422; Tue, 11 Feb 2020 10:05:03 -0800 (PST)
Received: from [192.168.43.200] ([92.184.96.212]) by smtp.gmail.com with ESMTPSA id r3sm6367278wrn.34.2020.02.11.10.05.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Feb 2020 10:05:02 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Henry Story <henry.story@gmail.com>
In-Reply-To: <20200211174543.GL18021@localhost>
Date: Tue, 11 Feb 2020 19:05:01 +0100
Cc: saag@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2EA72296-7533-4D92-97DF-99027EC46543@gmail.com>
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> <20200211174543.GL18021@localhost>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/tIXoRWofM2tDKc53EoPLXASAgTw>
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 18:05:10 -0000


> On 11 Feb 2020, at 18:45, Nico Williams <nico@cryptonector.com> wrote:
> 
>> 
>> 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 am not arguing against DNS-SEC Dane nor X509, but to
enlarge one’s view of how names get meaning. Those
two systems only allow one to tie a name to a referent.
They don’t give the meaning of a name, which it squires by
how it is related to other entities.

This is similar to ideas from Category theory, that
an object in a category is determined by its relation
to all other objects in that category. One does not
need the relation to all other things to be visible, for
a web site, but one needs more than a name. 

Paying Certificates provide a little more: an address. But that
is static, and epistemologically quite problematic: who knows
all geography so well that they can tell from an address 
where the site is located? 

> 
>> 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.

How can you ever improve your system if you start with such a
flawed psychological theory? 

Humans are not stupid. They have limited time to dedicate to
the task of understanding where an web site is located. This
could be improved by making the information
 1) enriching the information provided to be interesting and relvant
 2) by making the information dynamic
 3) and making it visible to the users.

You can’t do anything in the User interface of interest with the
information provided in certificates currently. That is just because
the information is so poor, and it is so poor because no private
entity wants to risk certifying more information than the minimal
amount. 

> 
>> 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.

That is equivalent to the standard argument from epistemological skepticism,
you cannot know that you are not dreaming, so how can you know anything.

It is not because you cannot remove all potential security threats, 
that you cannot make big steps forwards.

> 
>> 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.

Clearly you did not spend any time reading any of the links I sent
there. As you would see that my point is not that naming is broken
but that the linking between the names is non existent.

Henry