Re: [Secdispatch] [saag] The Mathematical Mesh

Nico Williams <nico@cryptonector.com> Wed, 24 April 2019 17:28 UTC

Return-Path: <nico@cryptonector.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 18DEB12010D; Wed, 24 Apr 2019 10:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 nLSgPkMVZtoR; Wed, 24 Apr 2019 10:28:48 -0700 (PDT)
Received: from cichlid.maple.relay.mailchannels.net (cichlid.maple.relay.mailchannels.net [23.83.214.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FBB21200F6; Wed, 24 Apr 2019 10:28:47 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 219C52C28C9; Wed, 24 Apr 2019 17:28:47 +0000 (UTC)
Received: from pdx1-sub0-mail-a82.g.dreamhost.com (100-96-11-130.trex.outbound.svc.cluster.local [100.96.11.130]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 52D4E2C20E6; Wed, 24 Apr 2019 17:28:46 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a82.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 24 Apr 2019 17:28:47 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Turn-Dime: 7e8c8d0b7edd552c_1556126926976_1125117772
X-MC-Loop-Signature: 1556126926975:2374531913
X-MC-Ingress-Time: 1556126926975
Received: from pdx1-sub0-mail-a82.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a82.g.dreamhost.com (Postfix) with ESMTP id A94887FE8E; Wed, 24 Apr 2019 10:28:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2CpHrdAShrvvvH to4JsvGM5PpMo=; b=g/6BeidDdH813gJapOKxMfseh8LT/En4Whd7ZXHgG0R3IK yVZK0dXYr5SVHeY31jCW23HpLL40DlGwwsTe822IYrZSYHN6Qqs9VcobKFSAJu1R RQuAVqP+tbYtHX0Bnwm+7gUpLBZQyEoq+uyzFoOyPq5Y94oaD5BYGujmbuXPE=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a82.g.dreamhost.com (Postfix) with ESMTPSA id 45B437FE77; Wed, 24 Apr 2019 10:28:43 -0700 (PDT)
Date: Wed, 24 Apr 2019 12:28:41 -0500
X-DH-BACKEND: pdx1-sub0-mail-a82
From: Nico Williams <nico@cryptonector.com>
To: Ben Laurie <ben@links.org>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, secdispatch@ietf.org, IETF SAAG <saag@ietf.org>
Message-ID: <20190424172840.GJ3137@localhost>
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> <CAG5KPzwr9oAP5270jE2N-Sw=d_g_YuhQ5_qB3W0OfggGrcU_qA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAG5KPzwr9oAP5270jE2N-Sw=d_g_YuhQ5_qB3W0OfggGrcU_qA@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrhedvgddtlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/6uBFbhp2GnzwJ_1DfroxhMTxB6g>
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: Wed, 24 Apr 2019 17:28:50 -0000

On Wed, Apr 24, 2019 at 09:53:01AM +0100, Ben Laurie wrote:
> 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.

Users absolutely have to be capable of being at least minimally aware.

Perhaps we should leave UI issues till much later, provided we get
consensus on a few "rules", with these as my proposal:

0) users absolutely have to be [capable of being] at least minimally
   aware of security

1) security UI indications should be minimally intrusive within
   constraint (0)


I'm sure there are many UI design options, such as:

 - non-modal  positive indicators
 - non-modal? negative indicators
 - reject negative interactions outright, with some sort of modal
   introducer option ("scan your peer's QR code" and such)
 - etc.

Perhaps with different UI choices for different kinds of devices.
Changes in device capabilities and form factors may well require
re-thinking UI design choices.

I don't care as much which if any or even all of the above are used, as
long as we get (0) and (1).

The degree of security indication UI intrusiveness is up for debate.  We
should give implementors guidance, but still let them experiment.

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

Thanks for this.  Can you provide a link to justification/blogs/research
about that change?

Nico
--