[therightkey] Informing the user they have the wrong key

Tony Arcieri <bascule@gmail.com> Sat, 27 September 2014 02:05 UTC

Return-Path: <bascule@gmail.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3301A010F for <therightkey@ietfa.amsl.com>; Fri, 26 Sep 2014 19:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 X2P2REYIxE6w for <therightkey@ietfa.amsl.com>; Fri, 26 Sep 2014 19:05:30 -0700 (PDT)
Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3CD21A00FB for <therightkey@ietf.org>; Fri, 26 Sep 2014 19:05:30 -0700 (PDT)
Received: by mail-ob0-f178.google.com with SMTP id va2so10982763obc.9 for <therightkey@ietf.org>; Fri, 26 Sep 2014 19:05:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=GNO8mDxCHd3iQ2LBK0be85WI+y2qHa2gFzFhToyiJxQ=; b=FZvCWfghdcvfX6/sCOQwcE0+g7sLCOGVfarZwnW+QiTfR0xdjR00I8juY2XfGSchbH 68OyB+mV0ba1iyPGvksjHwTeKxGrx9FQeCuh8ihD/f7DNF6rNpgPbCqZ1BPYFdKb3FVe M6jYGfaFA0NJNCJyLSi0BXUgni5GhpToGzLRY5/MquXEmFYZfDhZ8XeFWlIrM0oKBnIw mGRLYdnQmJ+oARjKFHCR1PohpApawS6uGdgmHol1S29sgaecthFpmnvZJzga7uV0e3DU 9Ys3ZNAU1D1D/eUnAHdjnwMVrXm3kSZwENR0edGpKvKLYo9MN5AqYoImFhSbQgl2V8Ao bacw==
X-Received: by 10.60.35.6 with SMTP id d6mr14906oej.77.1411783530150; Fri, 26 Sep 2014 19:05:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.59.8 with HTTP; Fri, 26 Sep 2014 19:05:10 -0700 (PDT)
From: Tony Arcieri <bascule@gmail.com>
Date: Fri, 26 Sep 2014 19:05:10 -0700
Message-ID: <CAHOTMVLTD27CCgUZOipr1+ERjpuYz2vX=ymP5rh6GXUucgm7Rw@mail.gmail.com>
To: messaging <messaging@moderncrypto.org>, therightkey@ietf.org, Crypto <cryptography@metzdowd.com>, cpunks <cypherpunks@cpunks.org>, liberationtech <liberationtech@lists.stanford.edu>
Content-Type: multipart/alternative; boundary="089e01228b1ad083d3050402771b"
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/mm9AkLyTrc5TF2UxdLplKUPre9s
Subject: [therightkey] Informing the user they have the wrong key
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Sep 2014 02:05:32 -0000

If we build fancy systems to detect things like misadvertised keys or MitM
attacks, how can we reasonably inform an end user what is amiss in an
actionable way that won't confuse them with too many false positives to
avoid taking action when something bad actually happens?

I recently went to SOUPS and saw a number of presentations on the general
difficulty of communicating security-actionable information to users. From
what I saw I'd say the problem is twofold:

1) How does the system provide a high confidence level that when it tries
to communicate a security-actionable event, it's fairly certain it's not a
false positive? False positives condition users to ignore security warnings

2) How do you express what's happening to the user in such a way that they
will actually take action on it and not just click-through dismiss it?

Given the wide-ranging number of scenarios, the answer will of course be
contextual, and I'd be curious to hear any replies about how systems try to
solve the "right key" user experience problem in general.

That said, the messaging use-case (in conjunction with a "key directory"
system) is particularly interesting to me.

If an end-to-end encrypted messaging system which relies on a
centrally-managed key directory (e.g. iMessage) were to by coersion or
compromise publish a poison key to their directory to facilitate a MitM
attack, but the system creators wanted to make such action obvious to their
users, how can the systems reasonably detect and reflect this in such a way
that such users aren't conditioned to ignore such alerts for routine events
(e.g. the SSH "SOMETHING NASTY" message) and actually feel compelled to
take action on that knowledge?

And then what? How can we help someone who is a victim of an attack like
this actually compile all of the necessary information for someone to
figure out what actually happened? How can encryption tools compile
incident reports that experts can scrutinize to determine what happened?

-- 
Tony Arcieri