Re: [saag] post-X509 cryptographic identities

Henry Story <henry.story@gmail.com> Fri, 14 February 2020 08:19 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 653C0120043 for <saag@ietfa.amsl.com>; Fri, 14 Feb 2020 00:19:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 ku3GdFGLOmCG for <saag@ietfa.amsl.com>; Fri, 14 Feb 2020 00:18:56 -0800 (PST)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 2BF6F120045 for <saag@ietf.org>; Fri, 14 Feb 2020 00:18:56 -0800 (PST)
Received: by mail-wr1-x430.google.com with SMTP id k11so9828596wrd.9 for <saag@ietf.org>; Fri, 14 Feb 2020 00:18:56 -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=+upDVMuNFmOZaevCi+TG2A2q5q7n5Gqqqf+ZdCSx+fo=; b=pSPoRkmNbuMiEGwFTcemZq67BQZS8f0PAtRZJ83aGwVZFDGBjktiXxp0Eeg7MCPc67 hMm9tCE/2Irg+R0KBuufzJ125+8p2cBT6g1dzb9COeSWJlvv1SOVp4+eLL+qdgBBwAJu YBDNjHkDoAZPY8ZrgEXodYOoS9ZivT217vz00PauaPVYbKXD6hRzhAaETJj555msy0el bTB+d3jFXf3gA0sCUEygwsaXK8FIykr4CRH2VF1o+3G9BExAr54xTFZ5iZPIkUFmFQ9K oR/tgL1laYr7KNLIO4NpPSDGRtFfRoKNuDXcVKyFZtJFXdqLX0t2X1txri2BFMmdYO5C DoOQ==
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=+upDVMuNFmOZaevCi+TG2A2q5q7n5Gqqqf+ZdCSx+fo=; b=od5FrMOgU0hPPLsK2HIzNa1DM3rlpiz8ckhr3nEsfP+MD2W7ESJNi6Lz/ZuR3bHmeg Pp681zMqOmpDIHH7sxQh1m4QOT+92bZ3Nd16kkYNk7PwSTKAWMhZx1xW07LAQnLoD2lv 5FEHQib3IzDhbWB8K5/ed1V/b0cCsHdlhAd+tbX39GMu2Fy7/Xw51UbEbf7UQJiqk1Te 139lZuQk/lPAvGUkq2hnRc3/YLH8QxR4pk4ODVY7lr2by9dLzblolmD2vwsxgZsEZvCj BFY7O7p15SGaqL3lamzV56apJoV45I5lhW4GLAglzJytcT2FewrZ9aPnDVgTkZuWnnpF m2Cw==
X-Gm-Message-State: APjAAAXoOmUzBsnFbLUfxK7XZuRUJJeuCjQ8VfoE84ya82A8v0sy2Yk6 Z+ZjnveomJIDqa3OKkcpB2IqRFmjgn4=
X-Google-Smtp-Source: APXvYqyx1xXKTdKgzcBCpDmCdetP2Ts38aa0c/0yW02RTcnIIW7SEfiLBWX1PSq4MRrkPynaCeuJMA==
X-Received: by 2002:a05:6000:1187:: with SMTP id g7mr2631079wrx.109.1581668334498; Fri, 14 Feb 2020 00:18:54 -0800 (PST)
Received: from [10.1.33.10] (ipb218ec89.dynamic.kabel-deutschland.de. [178.24.236.137]) by smtp.gmail.com with ESMTPSA id c9sm6710287wme.41.2020.02.14.00.18.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Feb 2020 00:18:53 -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: <20200213222012.GV18021@localhost>
Date: Fri, 14 Feb 2020 09:18:52 +0100
Cc: trutkowski@netmagic.com, Michael Richardson <mcr+ietf@sandelman.ca>, saag@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C33500CD-E04A-4B2A-82F4-0D12788629EF@gmail.com>
References: <d3d01f1f-5784-da84-1c59-e636d349bd2a@netmagic.com> <20200213175626.GR18021@localhost> <65357327-e2d7-89cc-221e-ed8ac2875048@netmagic.com> <A91F5BD6-BFBA-4BA7-9158-3F41A8F0F7D9@gmail.com> <20200213191952.GS18021@localhost> <9FEBBD2A-3578-436A-92E3-192CADC9FA8B@gmail.com> <20200213205158.GT18021@localhost> <43D1454A-C1DD-4742-A14C-F608F296208C@gmail.com> <20200213213953.GU18021@localhost> <8390efa4-a212-f0ee-d78e-8e997242d72a@netmagic.com> <20200213222012.GV18021@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/i3gR4dPXWjTZX8DSWWNOr0W_0O4>
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: Fri, 14 Feb 2020 08:19:00 -0000


> On 13 Feb 2020, at 23:20, Nico Williams <nico@cryptonector.com> wrote:
> 
> On Thu, Feb 13, 2020 at 05:02:16PM -0500, Tony Rutkowski wrote:
>> All important electrical communication identifier systems invariably end up
>> at the point of nation state regulation. Consider what is occurring now with
>> telephone CallerID which went through a full cycle of regulation to
>> deregulation to re-regulation.  There are several compelling bases.  On one
>> side, nation states have sovereign jurisdiction over all communication
>> within their geospatial boundaries and assert it for a swath of national
>> security and law enforcement reasons.  On the other, the providers seek
>> indemnification (antitrust and tort) and the end users an expectation of
>> trust and consumer protection.  Consider it a recognition of relevance.
>> 
>> The DARPA DNS itself went through a cycle of strong government regulation to
>> deregulation to Ira Magaziner's scheme for healthcare governance (a/k/a
>> ICANN) and now likely to re-regulation or irrelevance.
> 
> I am in full agreement.
> 
> It is fair to predict that anything new that might replace WebPKI or DNS
> will have to deal with regulation of registries eventually, and should
> be designed with it in mind.
> 
> I'm just quite skeptical that the DNS could be replaced.  The protocol,
> perhaps, some of the details, sure, but domainnames?  the registries?
> nah.  Anything new will have to be in-addition-to DNS for a long time,
> or bolted-onto DNS (e.g., DANE).

Indeed a lot has been built on these, and one can build a lot more.

> 
> Back to Henry S.'s call for more public metadata...  More metadata
> doesn't help the user.  E.g., when I need some less-well-known app from
> an app store, I often find apparent dups by different vendors, and it's
> hard to tell which one is legitimate if any, and the vendor names
> (metadata) often don't help in the least because they are obscure enough
> that the user can't really do anything with them -- the user is entirely
> at the mercy of the curators, and the curators are obviously not doing a
> good enough job.  Requiring more public metadata may not help at all,
> not without lots more regulation and off-line authentication of said
> metadata, with attendant problems.

Metadata just as data by itself is not the answer, of course. It all
depends on who is making the claim. If someone in a bar tells you
to take some medicine, it has a different value than if your
doctor tells you exactly the same thing in his office, even if both
use exactly the same words. 

So I am not making a call for "more public metadata” as if it were a question of quantity. What is important is for official enforceable 
data to be standardized so as to be useable by browsers and the OS to
help inform the user about what web site they are visiting for example,
or who is responsible for writing an app running on their device.

If an App store is to be thought of as a service that verifies application
then the only added data that legitimately the Store needs to assert is that they verified App ”TicTacToe” (to take an arbitrary example), that came from 
company <https://tictacktoe.example/> registered at <https://regitry.ca.us/co/TickTackToeCorp>.  

In terms of BAN logic of "saying that” [1] we need to distinguish who says what. Whether later you sign that statement or refer to a statement
someone else made is not logically that much of a difference.

AppStore says { <ttt> a VerifiedApp;
                      :verified <apps/ticktacktoe/>;
                      :source <https://tictacktoe.example/app/ttt>;
                      :builtBy <https://regitry.ca.us/co/TickTackToCorp> }
     
We think of { … } as quotes.
Of course if you download the info from AppStore’s web site then you won’t find AppStore says { … } just as when one speaks to someone one does not start every sentence by saying ”I say …”. That is something inferable from the pragmatic context, and verifiable on the web through TLS authentication 
for example. 

Still you may wonder: how do I know I am on the AppStore? 

Well it works for Apple and Android because their marketing power
is good enough that they can teach everyone in the world to remember
their URL (or indeed build it into their OS). 

But most other companies have to rely on trust because the links to real government registrars with legal clout is not there. If it were there it
could provide completely new security for Apps as I describe in this short
post applying Modal Logic used in Epistemology to User Interfaces.

https://medium.com/cybersoton/phishing-in-context-9c84ca451314

Henry


[1] https://en.wikipedia.org/wiki/Burrows%E2%80%93Abadi%E2%80%93Needham_logic
https://www.sciencedirect.com/science/article/pii/S1571066107000746

> 
> PS: The telephone system has the great misfortune of being stuck with
>    SS7; the DNS is ahead on security.