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

pgut001@cs.auckland.ac.nz (Peter Gutmann) Tue, 21 October 2008 14:56 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 2AD433A68DE; Tue, 21 Oct 2008 07:56:30 -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 A8AF53A68DE for <tls@core3.amsl.com>; Tue, 21 Oct 2008 07:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.563
X-Spam-Level:
X-Spam-Status: No, score=-4.563 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 gLRl6akg4bkM for <tls@core3.amsl.com>; Tue, 21 Oct 2008 07:56:28 -0700 (PDT)
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id A156A3A6916 for <tls@ietf.org>; Tue, 21 Oct 2008 07:56:25 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B2B9E9D33B; Wed, 22 Oct 2008 03:57:00 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYGxUhemh7S8; Wed, 22 Oct 2008 03:57:00 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 91FE29D33E; Wed, 22 Oct 2008 03:57:00 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id A303519EC0BB; Wed, 22 Oct 2008 03:56:59 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1KsIfL-000595-Hr; Wed, 22 Oct 2008 03:56:59 +1300
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: nelson@bolyard.me, tls@ietf.org
In-Reply-To: <48F79D30.7030104@bolyard.me>
Message-Id: <E1KsIfL-000595-Hr@wintermute01.cs.auckland.ac.nz>
Date: Wed, 22 Oct 2008 03:56:59 +1300
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

Nelson B Bolyard <nelson@bolyard.me>; writes:

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

I'm sure this can be argued endlessly, but given a mechanism that has 100%
coverage/penetration (cookies/Flash cookies/cache cookies/Javascript/whatever)
and one that has a coverage level two orders of magnitude below the margin of
error, I know which one I'd be using to track users, regardless of some
theoretical advantage that one might have.

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

UI folks did this?  Wow.  I guess they had no idea of the consequences of
their actions :-).

>The subsequent discovery of lots of sites that are doing this seems to prove
>that the threat was not merely imaginary.

That doesn't say anything about the threat, merely that there are lots of
misconfigured servers.  The fact that the server admins had no idea their
servers were doing this and even less idea how to turn it off, and that the
servers threw the certs away when they were given them, would argue strongly
against any attempt at deliberate user tracking.

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