Re: [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: 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 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/saag/KNlrGGf9sq0MgWKE17yh_nxMNbk>
Subject: Re: [saag] The Mathematical Mesh
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, 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.