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

Martin Rex <mrex@sap.com> Wed, 27 July 2011 21:29 UTC

Return-Path: <mrex@sap.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 279CF11E80A1 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 14:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.886
X-Spam-Level:
X-Spam-Status: No, score=-9.886 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 6R4nI2JlDj53 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 14:29:41 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D173811E813C for <tls@ietf.org>; Wed, 27 Jul 2011 14:29:40 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6RLTdXN011658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2011 23:29:39 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107272129.p6RLTcIm011843@fs4113.wdf.sap.corp>
To: anders.rundgren@telia.com
Date: Wed, 27 Jul 2011 23:29:38 +0200
In-Reply-To: <4E307CF1.60105@telia.com> from "Anders Rundgren" at Jul 27, 11 11:02:41 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
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
Reply-To: mrex@sap.com
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: Wed, 27 Jul 2011 21:29:42 -0000

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.
 

> 
> They find HTTPS' way of doing that intrusive.
> 
> On the web you logoff from (or by) the server.
> 
> Naturally logoffs must trickle down to clients
> if they have logged-in using HTTPS CCA otherwise
> they are de-facto logged-in due to the TLS caching.

"Logoff" is a pure server-side concept with respect to server-side
state.  A logoff concept that requires cooperation from the client
is technical nonsense.  Any server-side destruction of backend-state
associated with particular clients must work completely independent
of what the client does.  Early consensual destruction of backend
state if the client explicitly asks for it is OK.  But any
server-initiated "logoff" concept that involves the client
amounts to technical cluelessness.

And application level state management ought to be ***completely***
independent from the TLS session cache management.  The server
side TLS session cache management must be completely independent
from application level backend state management when you're
using a transport with non-persistent connections (such as HTTPS).

The lower protocol levels of the server must be free to manage
TLS session cache lifetime based on resource availability
and administrative or operational requirements, and short
server-side TLS session lifetimes (several minutes absolute lifetime),
server-side TLS session cache flushing (when performing
debugging on an otherwise productive system, or when updating
the server certificate or changing the list of trusted
client cert signers), as well as temporarily completely
disabling server side TLS session caching MUST NOT interfere
with application level session management.  Any application
that suffers from such server side TLS session cache
characertistics is seriously and thoroughly broken
(lack of abstraction and invalid protocol layering).


-Martin