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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 29 July 2011 06:39 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 E259211E808A for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 23:39:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.603
X-Spam-Level:
X-Spam-Status: No, score=-3.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 Y+yTd+T20juv for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 23:39:18 -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 01AF911E807F for <tls@ietf.org>; Thu, 28 Jul 2011 23:39:17 -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=1311921558; x=1343457558; 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<201107290006.p6T06BD0012180@fs411 3.wdf.sap.corp>|Message-Id:=20<E1Qmgj6-0007y4-DJ@login01. fos.auckland.ac.nz>|Date:=20Fri,=2029=20Jul=202011=2018:3 9:16=20+1200; bh=9WtnUz5C/c9+y55ltfIF8sMXKjBX48cko46Emld62dI=; b=r/kwza+2/0egSl52dz81Kipo9A4OQvCBUW6a0mKHeDhNLUv5SiP+1XQx 2ZPvA063dGibUVd2bohM1qM5+6M3zgK/wyEFAFS4TNY0aAHgvv4C1St/c ne3nfLsdjPeXL9fPLGLRrIjBnmldPF+I/93+dMK6VT8x8Ypy/IrituST5 Y=;
X-IronPort-AV: E=Sophos;i="4.67,286,1309694400"; d="scan'208";a="74803823"
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; 29 Jul 2011 18:39:16 +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 1Qmgj6-0000UT-Ha; Fri, 29 Jul 2011 18:39:16 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1Qmgj6-0007y4-DJ; Fri, 29 Jul 2011 18:39:16 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: mrex@sap.com
In-Reply-To: <201107290006.p6T06BD0012180@fs4113.wdf.sap.corp>
Message-Id: <E1Qmgj6-0007y4-DJ@login01.fos.auckland.ac.nz>
Date: Fri, 29 Jul 2011 18:39:16 +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: Fri, 29 Jul 2011 06:39:19 -0000

Martin Rex <mrex@sap.com> writes:

>I don't know what particular issue banks have with their weird threat model 
>here in Germany, I'm unable to find an even remotely reasonable explanation 
>why so many of them are suddenly violently determined to completely kill any 
>of their existing paper-based TANs, including iTANs that they introduced just
>a few years ago, aggressively touted as something that you need.

This has been covered in a number of journal/magazine articles, for example 
there was a fairly comprehensive one in c't in the middle of last year on 
this.  Since paper-based TANs aren't tied in any way to the transaction 
they're authenticating, they're vulnerable to both phishing attacks and MITB 
attacks.  iTANs were introduced to counter straight phishing (ask for the next 
n TANs), the attackers countered with more aggressive TAN phishing and MITB, 
and the response to that was mTANs and tokens.  So German banks are actively 
tracking threats as they evolve and responding to them, which few other banks 
seem to be doing (or at least if they are, it's not documented anywhere).

This is probably why US phishing losses are a staggering *six hundred times* 
higher than German ones.  In Germany the banks try and address evolving 
threats.  In the US the banks take their customers to court when they become 
victims of poor banking security.

Peter.