Re: [TLS] EU cards

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 30 July 2011 07:02 UTC

Return-Path: <pgut001@login01.cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B253921F8C81 for <tls@ietfa.amsl.com>; Sat, 30 Jul 2011 00:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.228
X-Spam-Level:
X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iG1-fqNHjDBT for <tls@ietfa.amsl.com>; Sat, 30 Jul 2011 00:02:16 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 61F4A21F852E for <tls@ietf.org>; Sat, 30 Jul 2011 00:02:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1312009336; x=1343545336; h=from:to:subject:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20tls@ietf.org,,=20uri@ll.mit.edu|Subject:=20Re:=20[ TLS]=20EU=20cards|Message-Id:=20<E1Qn3Yq-0007dr-2v@login0 1.fos.auckland.ac.nz>|Date:=20Sat,=2030=20Jul=202011=2019 :02:12=20+1200; bh=7QeaGG9fQgasJs+apk10DKKDIDUpubIyoeKCJiJm7r4=; b=jgUf/5WNzVUK3+UWxw5yhr3qohkVZkR+bCppn53/azqokFHZ1v6EEdHh 3m4lLAJIpOff0JLp26Wk0TxrTv0PMYyy8abkF66IYpxDlqlUfHf8gwYqr 5IDVH6y88tVJBMLA4Sa5NBaAyFhr5EdOUDcFBWZ39o/0oe6LEj0tBKQol Y=;
X-IronPort-AV: E=Sophos;i="4.67,291,1309694400"; d="scan'208";a="74888064"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Jul 2011 19:02:12 +1200
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1Qn3Yq-0007Ww-GZ; Sat, 30 Jul 2011 19:02:12 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1Qn3Yq-0007dr-2v; Sat, 30 Jul 2011 19:02:12 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: tls@ietf.org, uri@ll.mit.edu
Message-Id: <E1Qn3Yq-0007dr-2v@login01.fos.auckland.ac.nz>
Date: Sat, 30 Jul 2011 19:02:12 +1200
Subject: Re: [TLS] EU cards
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jul 2011 07:02:21 -0000

"Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu> writes:

>Have you used CAC?

My own experience with CAC (or other smart card/PKI technology) is totally
non-representative of typical end users, which makes me useless for
determining how typical users deal would with it.  This is why I go to end
users for feedback, or reference studies of end users performed by others.

>Then what do you know about how they suck or not?

By talking to end users?  A rather novel concept, I agree, but quite useful
for assessing the impact of something.

>I on the other hand have been using them for quite a while -

You're about as representative of typical end users as I am.  Whether you or I
can use them is largely irrelevant, because we're not typical users.  This is
something that the usability study that I referenced took pains to point out,
the people deploying the technology were incapable of understanding that just
because they managed to use it didn't mean that a normal user could.  In fact
when the paper was peer-reviewed, other security researchers had trouble
believing the empirical results obtained because it couldn't possibly take
users that long to obtain and configure a certificate ("I'm sorry but your
facts just don't support our theory").  The researchers who set up the study
had themselves managed to complete the task in two-and-a-half minutes.  The
test users (IT professionals who were given screenshot-by-screenshot paint-by-
numbers instructions showing them what to do) took two hours and twenty
minutes, and rated it as the hardest computer task they'd ever been asked to
perform.  That's about how representative you and I are of real-world users.

It's funny, there seems to be quite some dissatisfaction with CAC out there,
but no-one wants to talk about it in public because they'd risk losing face,
or government money, or both, if they did.  Within a few hours of my "Man,
that stuff SUCKS!" post I got three off-list responses from people who'd
worked with it which included comments like "When we rolled out CAC, our
support costs skyrocketed. It cost us more to support the damn thing than to
roll it out" (quoted verbatim from email).

Peter.