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

"t.petch" <ietfc@btconnect.com> Mon, 01 August 2011 20:36 UTC

Return-Path: <ietfc@btconnect.com>
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 A9A1B1F0C3F for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 13:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
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 2fAQuDB6UcYG for <tls@ietfa.amsl.com>; Mon, 1 Aug 2011 13:36:36 -0700 (PDT)
Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id B9A3F1F0C3E for <tls@ietf.org>; Mon, 1 Aug 2011 13:36:35 -0700 (PDT)
Received: from host109-153-78-164.range109-153.btcentralplus.com (HELO pc6) ([109.153.78.164]) by c2bthomr09.btconnect.com with SMTP id DXN33127; Mon, 01 Aug 2011 21:36:20 +0100 (BST)
Message-ID: <003f01cc5081$d8fa7e40$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, mrex@sap.com
References: <E1QmJoF-0004YD-Mk@login01.fos.auckland.ac.nz>
Date: Mon, 01 Aug 2011 21:30:14 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E370E43.002C, actions=tag
X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.8.1.193614:17:9.535, ip=109.153.78.164, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, ECARD_WORD, __HASHBUSTER_BLOCK_V2_1, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, HASHBUSTER_BLOCK_V2, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4E370E55.00BB, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
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: Mon, 01 Aug 2011 20:36:36 -0000

---- Original Message -----
From: "Peter Gutmann" <pgut001@cs.auckland.ac.nz>
To: <mrex@sap.com>
Cc: <tls@ietf.org>
Sent: Thursday, July 28, 2011 8:11 AM
Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers


> 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.
>

Coincidentally, one of the five big UK banks has today, 1st August, announced
HSBC Secure Key, a hand held card device that turns your PIN into a one-time six
digit passcode.  No technical details, but the advertisement claims that is is
an improvement on the German WWII devices (and half the advertisement is
encrypted - HX01896a1 54f30cd38 ...).  Another of the banks, Barclays, has had
PINsentry for a while, which takes your PIN and your debit card to generate a 8
digit passcode.

I have yet to use either but have seen technology similar to the former used
extensively in an Enterprise setting, for use by travelling salesmen in hotels
etc.

Tom Petch

> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls