Re: [saag] The Mathematical Mesh

Ben Laurie <ben@links.org> Wed, 24 April 2019 08:53 UTC

Return-Path: <benlaurie@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 7CA611202AB; Wed, 24 Apr 2019 01:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1bVh-cm8g4G; Wed, 24 Apr 2019 01:53:13 -0700 (PDT)
Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (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 83A1A120242; Wed, 24 Apr 2019 01:53:13 -0700 (PDT)
Received: by mail-qk1-f175.google.com 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; d=1e100.net; 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: <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> <CAMm+LwhEGTCG7Ucu7xiv0fYZHjxAhe5D6MdU6EYN4UTi0zLnrg@mail.gmail.com>
In-Reply-To: <CAMm+LwhEGTCG7Ucu7xiv0fYZHjxAhe5D6MdU6EYN4UTi0zLnrg@mail.gmail.com>
From: Ben Laurie <ben@links.org>
Date: Wed, 24 Apr 2019 09:53:01 +0100
Message-ID: <CAG5KPzwr9oAP5270jE2N-Sw=d_g_YuhQ5_qB3W0OfggGrcU_qA@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: Ben Laurie <benl@google.com>, secdispatch@ietf.org, IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ddd5df058742d43c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/XSTT2BymdBVFDw_2QJjkFQo8Hmg>
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: Wed, 24 Apr 2019 08:53:15 -0000

On Tue, 23 Apr 2019 at 22:23, Phillip Hallam-Baker <phill@hallambaker.com>
wrote:

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

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

Indeed.


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

Incorrect.


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