### Re: [Secdispatch] [saag] The Mathematical Mesh

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 23 April 2019 21:23 UTC

Return-Path: <hallam@gmail.com>

X-Original-To: secdispatch@ietfa.amsl.com

Delivered-To: secdispatch@ietfa.amsl.com

Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 95F2812038E;
Tue, 23 Apr 2019 14:23:05 -0700 (PDT)

X-Virus-Scanned: amavisd-new at amsl.com

X-Spam-Flag: NO

X-Spam-Score: -1.645

X-Spam-Level:

X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25,
FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001,
URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no

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 g3zE3CHuMrGY; Tue, 23 Apr 2019 14:23:04 -0700 (PDT)

Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com
[209.85.210.42])
(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 2C84512038D;
Tue, 23 Apr 2019 14:23:04 -0700 (PDT)

Received: by mail-ot1-f42.google.com with SMTP id t8so14205932otp.7;
Tue, 23 Apr 2019 14:23:04 -0700 (PDT)

X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=l0lnV4/b3RKKabkgl1MOZEkGE0qfz/+toe0t4rRON24=;
b=O2ijX6+RzC3rT22AD8ucUTmK6qTjbFqZ9fTdGyCxI81oLgfrtklc42BMJyNc/BElgy
Nxs/Lx8LGqXZMDL7neAcHJjpjar9Lg1Wwhyg8uNFGL0bg1R0hLcP2LLs7ZvHjixDa3do
ZOtSk53he/BGNa2N/9FlHQaB4+eekU5sCnv5to4MuLxhRsvP+8h0kj2BDxq13SF7eQgS
himO7xuXyJ2WUeb/z7Vn3jHO5LTFjul4DYWNuTGoPQg7UICSWHnbjcCqpFNk1dYp/0PZ
7SQgp1KsoL52nLrlt1gczU941p1BdaP2h+UWxNNvbt3BdbgELy2FhLG1L86vkSLkBi0Y
eJPw==

X-Gm-Message-State: APjAAAUFXZexjwL/DoZc2NZcTPrdUnqNyxUpjp94xq3L/lN934sAIcWk
To+5TyHO2+Ts8qEJOefEaQSASKvTwcyi18hM5m8=

X-Google-Smtp-Source: APXvYqxGlLB+4L4bKOc3yxSxpOCnCageSJvIfUMITMzEbj8YvRL9v8Lq74hWbFM0Qi+6mFpzfFGB/NGLje4Arj615Ps=

X-Received: by 2002:a05:6830:1017:: with SMTP id
a23mr17803530otp.120.1556054583391;
Tue, 23 Apr 2019 14:23:03 -0700 (PDT)

MIME-Version: 1.0

References: <CAMm+LwiF3iGiRO5reW4KCgf8vp=Kv=+4pD+_rGOcxEsD1Hxk4g@mail.gmail.com>
<20190422190302.GA3137@localhost>
<CAMm+Lwj1BV1=UQwE8-5tPO_mxOVixfkiUjXvu+U_AgnSzzkjvg@mail.gmail.com>
<CABrd9STVA=fT+oH7f4S_x8JQVaQRUJASWCY5g4pnhQL6ezWaHA@mail.gmail.com>

In-Reply-To: <CABrd9STVA=fT+oH7f4S_x8JQVaQRUJASWCY5g4pnhQL6ezWaHA@mail.gmail.com>

From: Phillip Hallam-Baker <phill@hallambaker.com>

Date: Tue, 23 Apr 2019 17:22:52 -0400

Message-ID: <CAMm+LwhEGTCG7Ucu7xiv0fYZHjxAhe5D6MdU6EYN4UTi0zLnrg@mail.gmail.com>

To: Ben Laurie <benl@google.com>

Cc: Nico Williams <nico@cryptonector.com>, secdispatch@ietf.org,
IETF SAAG <saag@ietf.org>

Content-Type: multipart/alternative; boundary="000000000000b1bce10587393013"

Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/tEy4j56E2IYxRIrFxIE4qbbnH9I>

Subject: Re: [Secdispatch] [saag] The Mathematical Mesh

X-BeenThere: secdispatch@ietf.org

X-Mailman-Version: 2.1.29

Precedence: list

List-Id: Security Dispatch <secdispatch.ietf.org>

List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>,
<mailto:secdispatch-request@ietf.org?subject=unsubscribe>

List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>

List-Post: <mailto:secdispatch@ietf.org>

List-Help: <mailto:secdispatch-request@ietf.org?subject=help>

List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>,
<mailto:secdispatch-request@ietf.org?subject=subscribe>

X-List-Received-Date: Tue, 23 Apr 2019 21:23:06 -0000

On Tue, Apr 23, 2019 at 8:16 AM Ben Laurie <benl@google.com> wrote: > > > On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker <phill@hallambaker.com> > wrote: > >> The primary focus is enabling real users to manage public key pairs on >> their devices without being aware that they are doing it. Securely >> establishing a set of public key pairs on each device and providing a >> validation path to the user's personal axiom of trust is the main idea >> here. Because if we achieve that, we are 80% of the way to securing almost >> any communication pattern. >> > > Where is the user testing for this? BTW, seems to me if users are not > aware that they are doing it, they will also not be aware when they are not > doing it. That doesn't seem like a path to security to me. > Please make that point to the Chrome team who are busy stripping out the security indicators so users don't know if they are on a secure site or not. I have done extensive user testing and come to the conclusion that almost none of it gives useful results. Most 'usability' testing methodology is designed to enable sales. So in 1980 when they started this, Apple was really interested in how to make the first 20 minutes of use as easy and productive a possible because that is the length of a typical sales session. What concerns me is how people behave in normal use when faced with an attack. The usability people do tests that tell them the security indicators are useless and strip them out so the user has no information to tell them whether something is secure or not. And not just Google's usability people, they all want to make the system easier to use by removing security. If you set up the test to look at people's behavior over short time intervals you will get a certain result. You also get that same result if you keep changing the security indicator. There are two concerns that must be addressed if a system is going to be usably secure: 1) The user must not be required to think about security when they are focused on their tasks. 2) The user must have the information they need to understand if their security concerns have been met. There are currently three device connection protocols, all provide a work factor of 2^120 or better. If we are using QR codes to connect devices, we can transmit the necessary information without the user needing to notice that is what we are doing. Otherwise, there are many existing protocols that make comparison of 15-30 character base 32 encoded strings as the basis for mutual authentication and these have proved effective and acceptable.

- [Secdispatch] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] The Mathematical Mesh Richard Barnes
- Re: [Secdispatch] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Ben Laurie
- Re: [Secdispatch] The Mathematical Mesh Michael Richardson
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Ben Laurie
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Ben Laurie
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Ben Laurie
- Re: [Secdispatch] [saag] The Mathematical Mesh Ben Laurie
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker