Re: [TLS] Verifying X.509 Certificate Chains out of order

Nelson B Bolyard <nelson@bolyard.me> Thu, 16 October 2008 19:58 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2893A6955; Thu, 16 Oct 2008 12:58:53 -0700 (PDT)
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D723A6955 for <tls@core3.amsl.com>; Thu, 16 Oct 2008 12:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSgUJLDoCwSh for <tls@core3.amsl.com>; Thu, 16 Oct 2008 12:58:51 -0700 (PDT)
Received: from smtpauth11.prod.mesa1.secureserver.net (smtpauth11.prod.mesa1.secureserver.net [64.202.165.33]) by core3.amsl.com (Postfix) with SMTP id 4DC003A6917 for <tls@ietf.org>; Thu, 16 Oct 2008 12:58:50 -0700 (PDT)
Received: (qmail 20107 invoked from network); 16 Oct 2008 19:59:48 -0000
Received: from unknown (64.202.165.33) by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 16 Oct 2008 19:59:48 -0000
Message-ID: <48F79D30.7030104@bolyard.me>
Date: Thu, 16 Oct 2008 12:59:44 -0700
From: Nelson B Bolyard <nelson@bolyard.me>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b2pre) Gecko/20081016 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: tls@ietf.org
References: <E1KqMBg-0006c8-WA@wintermute01.cs.auckland.ac.nz>
In-Reply-To: <E1KqMBg-0006c8-WA@wintermute01.cs.auckland.ac.nz>
Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

Peter Gutmann wrote, On 2008-10-15 23:18:
> I have a followup question for the topic of client-auth UI issues: [...]

> The OP said:
> 
>   For browsers, there arose a concern that automatic and silent client cert
>   authentication allows a web site to request cert authentication even when
>   the user has no business relationship with the site, and could be used for
>   user tracking, defeating anonymity of browsing.  So the default setting in
>   browsers was changed to manual selection to avoid silent user tracking.
> 
> So the tradeoff made was to significantly negatively impact usability in
> exchange for addressing a perceived privacy threat, specifically the fact that
> if I connect to a site that (for some reason) decides that it doesn't want to
> use traditional browser cookies or cache cookies or web bugs or Flash cookies
> or a million other ways of tracking users (including SSL session cache
> identifiers in the specific case of SSL) then they can now find out that I'm
> /C=US/O=Verisign/OU=Class 1 CA/OU=No liability accepted/CN=The Jolly Green
> Giant/email=qwertyuiop@hotmail.com.  Maybe I'm missing something here, but
> this seems to be a case of doing something that significantly negatively
> affects security usability (and therefore actual real security) in order to
> address an imaginary issue that only a geek could dream up.  Is there some
> other issue here that I'm missing?

One major difference between tracking with cookies (or TLS session IDs) and
using certs is that cookies and TLS session IDs contain only information
previously put there by the server itself.  When the server fetches them,
it doesn't learn anything about the user that it didn't already know.
It has merely learned that a user who has previously been to this web site
has now returned.  But certs reveal information that could well have
previously been unknown to the server.  Fetching certs is a way to do
information discovery.

As for this being a significant negative usability impact, soon the browser
will be able to remember a user's choices about certs for servers, including
the choice of "send no cert", and thereafter, the browser will no longer
bother him to repeat a choice he has already made. So, the impact will
typically be at most one choice per site. There will be no negative
usability impact for servers to whom the user really wants to authenticate.
A user won't mind choosing a cert for authenticating to his bank.  He will
mind being asked to choose while browsing porn. :)

Finally, I will add that the decision to change the default behavior for
client auth was made by the browser UI folks, not by the crypto folks.
The folks who made this decision are the UI czars who make the big
decisions about the trade off of usability vs other things (such as
security). They apparently thought the threat of this form of tracking
was serious enough to warrant the change.  The subsequent discovery of
lots of sites that are doing this seems to prove that the threat was not
merely imaginary.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls