Re: [therightkey] [messaging] Informing the user they have the wrong key

Michael Farb <mwfarb@cmu.edu> Mon, 29 September 2014 15:43 UTC

Return-Path: <mwfarb@cmu.edu>
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 9916A1A87EE for <therightkey@ietfa.amsl.com>; Mon, 29 Sep 2014 08:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.086
X-Spam-Level:
X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 G2spb7etaJPm for <therightkey@ietfa.amsl.com>; Mon, 29 Sep 2014 08:43:39 -0700 (PDT)
Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 787B71A87E0 for <therightkey@ietf.org>; Mon, 29 Sep 2014 08:43:39 -0700 (PDT)
Received: from mac1mwfwifi.wv.cc.cmu.edu (MAC1MWFWIFI.WV.CC.CMU.EDU [128.237.214.251]) (user=mwfarb mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id s8TFhVn9002449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Sep 2014 11:43:32 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_741DC15B-9174-4741-902B-205D07DFCE2C"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Farb <mwfarb@cmu.edu>
In-Reply-To: <CAHOTMVLTD27CCgUZOipr1+ERjpuYz2vX=ymP5rh6GXUucgm7Rw@mail.gmail.com>
Date: Mon, 29 Sep 2014 11:43:31 -0400
Message-Id: <BDB0579C-7B9D-4847-A2A0-94FBFE862AE5@cmu.edu>
References: <CAHOTMVLTD27CCgUZOipr1+ERjpuYz2vX=ymP5rh6GXUucgm7Rw@mail.gmail.com>
To: Tony Arcieri <bascule@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.29.153620
X-SMTP-Spam-Clean: 8% ( MULTIPLE_RCPTS 0.1, MIME_LOWER_CASE 0.05, SUPERLONG_LINE 0.05, BODYTEXTH_SIZE_10000_LESS 0, BODY_SIZE_10000_PLUS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __C230066_P5 0, __CP_MEDIA_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __FORWARDED_MSG 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_TRUST 0, __FRAUD_WEBMAIL 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IN_REP_TO 0, __MIME_HTML 0, __MIME_VERSION 0, __MSGID_APPLEMAIL 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_NS )
X-SMTP-Spam-Score: 8%
X-Scanned-By: MIMEDefang 2.74 on 128.2.105.202
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/ewGpON_m9Js40IP6-WTsGn8SFsU
X-Mailman-Approved-At: Mon, 29 Sep 2014 13:19:20 -0700
Cc: messaging <messaging@moderncrypto.org>, cpunks <cypherpunks@cpunks.org>, therightkey@ietf.org, Crypto <cryptography@metzdowd.com>, liberationtech <liberationtech@lists.stanford.edu>
Subject: Re: [therightkey] [messaging] 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: Mon, 29 Sep 2014 17:44:13 -0000

I'm not sure what the best way to do this in the asynchronous case, where I may have keys but have not validated their correctness and I want a process where I can verify against public data on a server at anytime. 

However, for synchronous cases, where 2 or more users are leveraging an existing physical meeting, video chat, or phone call, we establish key correctness (and initial exchange if needed) resolving some of these issues. SafeSlinger reports MITM interference in the exchange to the UI and aborts its protocol for all users, and prevents habituation of click-through by forcing users communicate out of band to choose matching words among some decoys.

But this case is active verification, I think you're referring to passive verification. I'd be interested to hear what others have to say. We use language like "unexpected data found in the exchange" in the active case. Perhaps the passive case should include a system of time sensitive escalation. Notifications come to the user about the suspect key that its authenticity is suspicious and can be used but will be reported compromised by the directory in X amount of time. Perhaps there should be rectification process with the directory publisher to troubleshoot keys before the X time?

Cheers,
Mike

Michael W. Farb
Research Programmer, Carnegie Mellon University CyLab
M 412-965-4725 - www.cylab.cmu.edu/safeslinger

On Sep 26, 2014, at 10:05 PM, Tony Arcieri <bascule@gmail.com> wrote:

> 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
> _______________________________________________
> Messaging mailing list
> Messaging@moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging