Re: [Secdispatch] [saag] The Mathematical Mesh

Ben Laurie <> Wed, 24 April 2019 08:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CA611202AB; Wed, 24 Apr 2019 01:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Status: No, score=-1.647 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d1bVh-cm8g4G; Wed, 24 Apr 2019 01:53:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83A1A120242; Wed, 24 Apr 2019 01:53:13 -0700 (PDT)
Received: by with SMTP id m137so6658742qke.3; Wed, 24 Apr 2019 01:53:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9wxstN3a8zUR+X9QIslPu+2ElNc1YUs2NBndJn0kRwE=; b=NkRZwZBGbrg5r/hquLUOxev+DSrJ9ZOHmvSQ0KILf2gRFL5CqkWu5GY0cgvpI9MWni pLa0lYTpVMnV0t3GNE4EM2xlmvxIjMf3ykMEBNTZ3tbBWEt9bilOQg9FOYadHDco8XVS /FakmrhWjmqFNA1uL2iVs0T7QsqFiibdEFjRlbUJlna90YNqEcbLxKS53v85OeO+Kadu kE0aja4idnl/EoWV6xZbqZeQCsLoQ3BbaRuTfk7+QjluODqRcMQ8aL05KVhxP+q7Uja1 /cwFfsC1JPYfL8XDyHjg4iH38BUf50iIo50AUTFhiee1iaNHHF0tQUH+dfP8ObBpiMcD U92w==
X-Gm-Message-State: APjAAAVrHO55ZbyIAiQ5SzYR8YhmdGUU57TAXZJtqp+K3668SQB8w9UT 9hQo64k69SYCLyNwchxjsKFqRHNgfp2FGYzs9yA=
X-Google-Smtp-Source: APXvYqzqN890hnOZQypWFXsxIPetadJXgUBR42MH5wgYsJjEgJ19Q9JiGRJWXv9/eG7vBBt7uKEypqC/6j+8HOc4r/s=
X-Received: by 2002:a37:63cf:: with SMTP id x198mr16961396qkb.353.1556095992450; Wed, 24 Apr 2019 01:53:12 -0700 (PDT)
MIME-Version: 1.0
References: <> <20190422190302.GA3137@localhost> <> <> <>
In-Reply-To: <>
From: Ben Laurie <>
Date: Wed, 24 Apr 2019 09:53:01 +0100
Message-ID: <>
To: Phillip Hallam-Baker <>
Cc: Ben Laurie <>,, IETF SAAG <>
Content-Type: multipart/alternative; boundary="000000000000ddd5df058742d43c"
Archived-At: <>
Subject: Re: [Secdispatch] [saag] The Mathematical Mesh
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Apr 2019 08:53:16 -0000

On Tue, 23 Apr 2019 at 22:23, Phillip Hallam-Baker <>

> On Tue, Apr 23, 2019 at 8:16 AM Ben Laurie <> wrote:
>> On Mon, 22 Apr 2019 at 20:33, Phillip Hallam-Baker <>
>> 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.

That is not what is happening. Chrome is switching from showing positive to
negative indicators.

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

Also incorrect.

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

I agree with both of these points. I have no idea why you think you can get
to this state without doing user testing.

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

Oh really? Evidence?