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

pgut001@cs.auckland.ac.nz (Peter Gutmann) Thu, 16 October 2008 06:17 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 5782D3A6B53; Wed, 15 Oct 2008 23:17:44 -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 110313A6B4F for <tls@core3.amsl.com>; Wed, 15 Oct 2008 23:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.054
X-Spam-Level:
X-Spam-Status: No, score=-6.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 suseBpX3iAkw for <tls@core3.amsl.com>; Wed, 15 Oct 2008 23:17:42 -0700 (PDT)
Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by core3.amsl.com (Postfix) with ESMTP id 112383A6B53 for <tls@ietf.org>; Wed, 15 Oct 2008 23:17:40 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9AA664820AA for <tls@ietf.org>; Thu, 16 Oct 2008 19:18:21 +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 (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46wTDREOCexk for <tls@ietf.org>; Thu, 16 Oct 2008 19:18:21 +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 8130E4820A8 for <tls@ietf.org>; Thu, 16 Oct 2008 19:18:21 +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 2461D19EC0BA for <tls@ietf.org>; Thu, 16 Oct 2008 19:18:21 +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 1KqMBg-0006c8-WA for tls@ietf.org; Thu, 16 Oct 2008 19:18:21 +1300
From: pgut001@cs.auckland.ac.nz
To: tls@ietf.org
Message-Id: <E1KqMBg-0006c8-WA@wintermute01.cs.auckland.ac.nz>
Date: Thu, 16 Oct 2008 19:18:20 +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

I have a followup question for the topic of client-auth UI issues: In my
initial response I made the standard geek mistake of leaping in to address the
technical problem ("ah, I see your problem, you need to oil the guillotine and
then the blade won't stick any more") without examining the underlying
assumptions that it was based on.  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?

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