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

Anders Rundgren <anders.rundgren@telia.com> Thu, 28 July 2011 08:42 UTC

Return-Path: <anders.rundgren@telia.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 DE1ED21F8C56 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 01:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.442
X-Spam-Level:
X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.158, 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 FKX7sttXcW5h for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 01:42:27 -0700 (PDT)
Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 1125921F8C4A for <tls@ietf.org>; Thu, 28 Jul 2011 01:42:27 -0700 (PDT)
Received: from [192.168.3.119] (193.12.106.2) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F00807BA0; Thu, 28 Jul 2011 10:42:21 +0200
Message-ID: <4E3120DD.7090306@telia.com>
Date: Thu, 28 Jul 2011 10:42:05 +0200
From: Anders Rundgren <anders.rundgren@telia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
References: <E1QmJoF-0004YD-Mk@login01.fos.auckland.ac.nz>
In-Reply-To: <E1QmJoF-0004YD-Mk@login01.fos.auckland.ac.nz>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 08:42:28 -0000

So now we have come to the point where all forms of client-
hosted keys used for authentication must die.

Maybe you guys should join forces with Microsoft who after
completely screwing up PKI and InformationCards, now turn their
hope (and money) to putting all your keys in the "Cloud"?

Platform security is a journey and it is by no means finished.

Mobile phones that are less plagued by legacy and backward
compatibility issues, will meet "the market's" security needs.
Well, I excluded the 0.01% that for unknown reasons believe
that security is more important than "getting the job done".

Anders
A really bad guy :-)

On 2011-07-28 08:11, Peter Gutmann wrote:
> 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.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>