Re: [TLS] HTTPS client-certificate-authentication in browsers

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 28 July 2011 06:11 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 4F46621F8BF2 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 23:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.62
X-Spam-Level:
X-Spam-Status: No, score=-3.62 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 1rbXHKJydqT7 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 23:11:14 -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 6453221F8BF0 for <tls@ietf.org>; Wed, 27 Jul 2011 23:11:13 -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=1311833474; x=1343369474; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20HTTPS=20clie nt-certificate-authentication=20in=20browsers|Cc:=20tls@i etf.org|In-Reply-To:=20<201107272129.p6RLTcIm011843@fs411 3.wdf.sap.corp>|Message-Id:=20<E1QmJoF-0004YD-Mk@login01. fos.auckland.ac.nz>|Date:=20Thu,=2028=20Jul=202011=2018:1 1:03=20+1200; bh=Xaz7yXUeyk29zwLL+dzv2kMxRWPYwRT4MABHO1S6Y8k=; b=FOJPnuTo4cWdxaxkCtF3PWk4EqS3VMwSZDdOFpyMVblfzWHmXDkDpR4e 2M0UdLKTErwa7bPvJX3iZO+cKfKpjDVO/gU7URzP9Ge8iAxUj8Jg7SXt1 eigjuXtbrflogNUtiV7RNLWrwizZ+kH3jZarFhp/i6+5WBmeE4f5vnFiS M=;
X-IronPort-AV: E=Sophos;i="4.67,280,1309694400"; d="scan'208";a="74570277"
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; 28 Jul 2011 18:11:03 +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 1QmJoF-0006I7-IX; Thu, 28 Jul 2011 18:11:03 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1QmJoF-0004YD-Mk; Thu, 28 Jul 2011 18:11:03 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: mrex@sap.com
In-Reply-To: <201107272129.p6RLTcIm011843@fs4113.wdf.sap.corp>
Message-Id: <E1QmJoF-0004YD-Mk@login01.fos.auckland.ac.nz>
Date: Thu, 28 Jul 2011 18:11:03 +1200
Cc: tls@ietf.org
Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers
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: Thu, 28 Jul 2011 06:11:15 -0000

Martin Rex <mrex@sap.com>; writes:
>Anders Rundgren wrote:
>> Lots of banks wants to use CCA for their users.
>
>That is a non sequitur.
>
>Banks (here in Germany) have abandoned tradtional TANs based on the 
>unconditional presumption that client PCs are infested with malware, and 
>most banks in Germany are currently replacing indexed TANs (iTAN) presumably 
>based on the perception that malware on clients (trojans/phishing) has caught 
>up with iTAN procedure complexity.
>
>At this point, with the presumption that all client PCs are thoroughly 
>infested with malware, going for a Single Sign-On mechanism would be 
>completely braindead and irresponsible.

That was my feeling as well.  Moving from TANs (or plain passwords if you're a 
US bank) to client certs is at best pointless and at worst a step backwards in 
security.  Even if you could overcome the monumental usability problems (and 
there's no evidence that we can do this), you end up with a mechanism that's 
even less secure than basic TANs because use of a TAN requires human 
intervention while a MITB (man-in-the-browser) can use your private key to 
sign whatever they want as often as they want without your knowledge.  Client- 
side PKI was designed for an attack model invented by cryptographers to 
justify the use of fun crypto stuff, but it has little (if anything) to do 
with the threats that we're actually facing today.

Peter.