Re: [saag] post-X509 cryptographic identities

Henry Story <henry.story@gmail.com> Tue, 11 February 2020 20:12 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 056D1120251 for <saag@ietfa.amsl.com>; Tue, 11 Feb 2020 12:12:03 -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 R1C-bSZ62dQ2 for <saag@ietfa.amsl.com>; Tue, 11 Feb 2020 12:11:59 -0800 (PST)
Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (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 B73DA120818 for <saag@ietf.org>; Tue, 11 Feb 2020 12:11:58 -0800 (PST)
Received: by mail-wm1-x341.google.com with SMTP id p9so5323588wmc.2 for <saag@ietf.org>; Tue, 11 Feb 2020 12:11:58 -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=NKTN/HA1FDFJT7l3Cqoabz43Eja7E1gm5zrqa6j94HY=; b=Q2Yf8kuSl+33J/liywR97HvNcOX2Xjbhs8n85rEJ+NsewHSgA5lxtqK0Ib9NKpxKIH fKkLV5U+20UrFzkaMf6tZhiX9bIiNZpozfh5yYO9m694SJbDxc1EQ0hJsz2FQPlfjOfD L69wxXMfM/2oMmyJ1Gz5fygvl6Kjh/Au6TavQ1SFy7pgGG97BhHd1vkCczpqpw/bpt6/ G6wdlmBslOlk8YOJbyYrfW9O9zWkUtbCoLSSvd8/76RQ8iyHCzrr+xOeeVK6MdemhhPa qkl/AWQaW/Si9HfYdEfHPLlf73foJM9fWYvylwKL41ogRlcD31BIxQ4Ov+mFE6rhlhBx a4IQ==
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=NKTN/HA1FDFJT7l3Cqoabz43Eja7E1gm5zrqa6j94HY=; b=tDFmIV1eu15WBxtd0VKgo5m2lrCh0vNAE6vNsfu0CDxlG0LrWPSRSmburXd22YQuBq Xe1dNiJYVQYPajJ4lzZ+rRrQVHqjkGaQYwa/mCmLdo4SDacfqI9r94rOoSTn/fZuHWqz xVXYiiX+O5MF+OxLMXuxHOfGoesG7LZWBBtmEIf9dGXwMS9+A4zYMxDmW8Z7QmzCx9Y8 zoJjfkFrP48aKE2JbajUOi5/TdEOhRDRb73vXX3vkCfqwHflEwssVXOYiyB/ZdpKRlt6 PizKWNg1am0VOl6+5YsBFT/utAY5+oknx6k4KTH+k8wrZWQS8cH//KCZDHHXeaUxSCRK BX/A==
X-Gm-Message-State: APjAAAWXNNtBcJONZ14vuoSHXKlKptQ9eVAjHs+RY3TJgJsbiyOkd9SS GS0C4UoSv9GaIzZFJw1oQQE=
X-Google-Smtp-Source: APXvYqzcYPDqMuwT7dox0cbX2Abl/MERQSNu0L0FN+wccNOmVR6F7h3im4i/4UOf8mhsVvrSdtY1eg==
X-Received: by 2002:a7b:c851:: with SMTP id c17mr7408234wml.71.1581451917065; Tue, 11 Feb 2020 12:11:57 -0800 (PST)
Received: from ?IPv6:2a02:810d:140:c5a:a8a0:c946:4242:ec9a? ([2a02:810d:140:c5a:a8a0:c946:4242:ec9a]) by smtp.gmail.com with ESMTPSA id 4sm4983202wmg.22.2020.02.11.12.11.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Feb 2020 12:11:55 -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: <20200211191713.GM18021@localhost>
Date: Tue, 11 Feb 2020 21:11:54 +0100
Cc: saag@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BDDD2111-246F-49CF-AF34-4D7C1D958F5E@gmail.com>
References: <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> <2EA72296-7533-4D92-97DF-99027EC46543@gmail.com> <20200211191713.GM18021@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/t7FPY-iaTEku9s2wPda-xDU1EkU>
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 20:12:03 -0000


> On 11 Feb 2020, at 20:17, Nico Williams <nico@cryptonector.com> wrote:
> 
> On Tue, Feb 11, 2020 at 07:05:01PM +0100, Henry Story wrote:
> 
> [Quoting out of order]
> 
>> 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. 
> 
> This is one thing we can improve: the binding of HTTPS URL authority to
> an actual owner.  The certificate is useless, indeed, and cannot bring
> any more metadata into the picture than the hostname -- the binding of
> that to authorization by a proper owner is essential, and the WebPKI
> cannot provide this well enough.
> 
> Providing _more_ metadata likely won't help human users: they can barely
> cope with the concept of a domainname, let alone more stuff.

I believe you are drawing completely the wrong conclusions from the
data. In my view they can’t cope with the domain name info because
it is completely uninteresting (given the many other tasks they are
involved in when using the Web). 

Just try to think your way back to a user first discovering the 
certificate description box. What information do they find there
that would warrant them coming back? Do they find a telephone number?
Shop opening times? information about if the CEO landed in Jail?
No. They may just find a URL. Why would anyone ever come back?

They then find that a certificate authority signed it. Who is that CA?
No idea. 

Now adding more data does not of course help if you don’t display it
intelligently. That is what designers make their profession. But they
can’t do anything if there is nothing to display.

> 
>>> On 11 Feb 2020, at 18:45, Nico Williams <nico@cryptonector.com> wrote:
>>> 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.
> 
> I don't think I implied that you were.
> 
>> [...]
> 
> You're headed right for the identity problem, and thorny problems in
> philosophy like the Ship of Theseus problem.

The Ship of Theseus problem is the ancient puzzle that asks if the ship
is the same if one changes one plank, then another, … until one has
changed all planks.

That is: it is about the identity of a changing thing over time. When is 
it the same and when is it other? The answer depends on one’s criteria of identity for a given type of thing. Usually opinions vary.

In our situation the question would be: when is the site the same 
and when different?  Is it different 
- when a page changes? No
- when the owners change? Perhaps…
- if the owners stay the same but move to different country? …
   what if that country is at war with yours?

Importantly: this criterion of identity does not need to be decided once and
for all, in abstraction of all individual cases. 

The user can decide on a set of policies to make him aware 
depending on his relation to the owner of the domain. Eg. 
a user that has a contracts with that domain, would be very 
interested in knowing that a web site has changed legal space.
Someone going to a restaurant may be very interested if the cook
changed.

These criteria can be set by the user and these may be enhanced
in some countries by legal requirements. Eg. an owner can’t claim
his web site is different and that he does not have to abide
by his contracts because he changed a page.

> 
> You will not find an answer to these problems in cryptography.

I agree. 

> 
> All of our naming schemes have a layer of indirection where the tie to a
> physical entity is weak (a physical entity whose own "identity" is
> weak).

yes. My claim is that one needs to tie these into national or regional
institutions that have been set up for over a century to do this job.
The UK has a company index called Company House that has JSON machine
readable versions of their records.

See the curl example on 
https://medium.com/cybersoton/stopping-https-phishing-42226ca9e7d9


> 
>>>> 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? 
> 
> Oh?
> 
>> 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
> 
> Humans are _often_ quite stupid.  Not always, but also not never.
> 
>> 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 quickly run into issues.  UIs that are too busy.  Different people
> having different attention spans, different likes and dislikes for UIs.
> 
> There is no one-size-fits-all UI.

Exactly. That is why UIs have to be personalized. It’s not an easy job,
but it is not impossible. Look at how many people are using Unix now
that it has a GUI called Android or one called iOS. (In the early
1990ies people would laugh if you told them that Unix would be
widely used because they would boggle quite rightly at the idea
that everyone would use the command line).

> 
> Browser developers have been struggling for decades with this problem.

yes, because there is no information for them to work on!

> 
> "Look to epistemology" is a platitude.

Btw. I don’t just say ”Look to epistemology”.

I have an analysis of where the problem comes from, and some suggestions
on where one has to look to fix it. It is not easy to see, because
it is in very different place from where the IETF has its focus
(to simplify: protocols) whereas here we are thinking of linking
nations into a peer to peer decentralized social network: a Web
of Nations, in order to provide users information about the legal space
of web sites they are in. So one has to have a view of the whole space
of what makes an individual: what they do, the society they are in, the relations of those societies to each other and to yours, … and the tools
they are using which transforms the above space.



> 
> Nico
> --