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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 28 July 2011 14:45 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 7483B21F8C77 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 07:45:16 -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 oXl5E6eY2ZxN for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 07:45:15 -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 1275F21F8C71 for <tls@ietf.org>; Thu, 28 Jul 2011 07:45:12 -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=1311864315; x=1343400315; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20stefan.winter@restena.lu,=20tls@ietf.org|Subject: =20Re:=20[TLS]=20HTTPS=20client-certificate-authenticatio n=20in=20browsers|In-Reply-To:=20<4E31299F.6060400@resten a.lu>|Message-Id:=20<E1QmRpn-0006TH-5l@login01.fos.auckla nd.ac.nz>|Date:=20Fri,=2029=20Jul=202011=2002:45:11=20+12 00; bh=m1c3An9jDVjwu30p55R65HaTMoz2FybN+ubxr4XVtVU=; b=rIVpVqPHP2WErY+tDW7XpMdrywTx0Xr7863YfNCG+U8maq2SA6W7g0zm zkOd1e1nU81oK+p5Wyzd1ZoORjYNln1UdEahb+iLOrgl8LHvzbWgTgt1U j/p8RqZWNwOVr7eYwwFS23nyXP9s/VbO5XQSrNxWLBsNnQ2bXB4QxteQG I=;
X-IronPort-AV: E=Sophos;i="4.67,282,1309694400"; d="scan'208";a="74606615"
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 02:45:11 +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 1QmRpn-0005Za-Gq; Fri, 29 Jul 2011 02:45:11 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1QmRpn-0006TH-5l; Fri, 29 Jul 2011 02:45:11 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: stefan.winter@restena.lu, tls@ietf.org
In-Reply-To: <4E31299F.6060400@restena.lu>
Message-Id: <E1QmRpn-0006TH-5l@login01.fos.auckland.ac.nz>
Date: Fri, 29 Jul 2011 02:45:11 +1200
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 14:45:16 -0000

Stefan Winter <stefan.winter@restena.lu> writes:

>Banking: These days, TAN lists are going away.

Is there any information on what's being done in countries like France, Italy,
the Netherlands, Spain, ...?  The only place where it's really documented (in
quite some detail) is Germany (with surrounding/similar countries like Austria
and Switzerland using equivalent approaches), but what are other countries in
Europe doing?  There's rather little information *from third parties, not the
vendors* publicly available on how e-banking is done in France, Spain, ...,
the pros and cons, how it deals with new attack types, and so on.

>a) cell phone transaction numbers:

The problem is that mTANs are vulnerable to smartphone malware, as Zeus has
already shown.  It's currently a minor threat, but who knows how far the bad
guys will take it.  On the whole though mTANs are a nice tradeoff, you get to
verify the transaction over an independent channel, and the mTAN is a
cryptographic hash over the transaction data so if a MITB tries to modify what
the browser sends it gets detected.

Peter.