W3C home > Mailing lists > Public > public-wsc-wg@w3.org > July 2007

RE: ACTION-240 :TLS errors...

From: Dan Schutzer <dan.schutzer@fstc.org>
Date: Thu, 19 Jul 2007 11:14:11 -0400
To: "'Serge Egelman'" <egelman@cs.cmu.edu>, "'Johnathan Nightingale'" <johnath@mozilla.com>
Cc: "'W3C WSC Public'" <public-wsc-wg@w3.org>
Message-ID: <010301c7ca17$7bbc3920$2d0010ac@dschutzer>

Can you send me some references to your work in Key continuity management?
Thanks

Dan

-----Original Message-----
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On
Behalf Of Serge Egelman
Sent: Wednesday, July 18, 2007 10:11 AM
To: Johnathan Nightingale
Cc: W3C WSC Public
Subject: Re: ACTION-240 :TLS errors...


Righto, I now see what he meant and am in complete agreement.  This is
delving into not just keeping track of root certificates (which I think
you all know my opinion on), to keeping track of every certificate.
Peter Gutmann and Simson Garfinkel have done some work on this-- "key
continuity management", and I think this would be a good recommendation
for us to make.  It's trivial to keep track of every host/certificate
tuple, just as browsers already keep track of form information.

serge

Johnathan Nightingale wrote:
> 
> On 18-Jul-07, at 9:48 AM, Serge Egelman wrote:
> 
>> Well, you said that this "is the poster child for exploiting browser
>> state."  For it to be a serious threat that warrants consideration, you
>> must assume that most users read certificate data (regardless of whether
>> the browser is actually throwing a warning).  If we can assume that most
>> users do *not* read this information, then there's a plethora of much
>> easier/likelier attacks.
>>
>> That is, it's a waste of time worrying about how a burglar might pick
>> your fancy new lock when you regularly leave all the windows open.
> 
> Serge,
> 
> I might be wrong here, but I think you are talking past each other
> because I think you are misunderstanding Thomas' use of the word
> "exploiting".  His original quote, in response to the discussion about
> using a self-signed cert to facilitate a man in the middle attack, was:
> 
>> Isn't this a poster child use case for exploiting browser state?
>> E.g., exploiting the knowledge that a certain domain in connection
>> with HTTPS used to have a CA-based cert, and warning when that
>> changes?
> 
> By which I believe he meant:  "This nicely illustrates why it would be
> useful for browsers to maintain state about prior SSL connections so
> that, in the event - however unlikely - that you visit a site which used
> to have a CA-signed cert, but which now instead presents a self-signed
> one, the browser can make all manner of noise/aggressive blockage, since
> that scenario is magnificently unlikely for any legitimate bank,
> webstore, etc."
> 
> I think he meant "exploiting browser state" as "leveraging browser state
> to do good things for users" not "attacking browser state, here's a new
> threat for us to consider."
> 
> As I say, maybe I'm wrong, and you're reacting to the idea as I
> (re-)expressed it, but one of us is being tripped up by email-fail,
> because I'm having trouble following your arguments against (what I
> understand to be) his point.
> 
> Cheers,
> 
> Johnathan
> 
> ---
> Johnathan Nightingale
> Human Shield
> johnath@mozilla.com
> 
> 
> 

-- 
/*
Serge Egelman

PhD Candidate
Vice President for External Affairs, Graduate Student Assembly
Carnegie Mellon University

Legislative Concerns Chair
National Association of Graduate-Professional Students
*/
Received on Thursday, 19 July 2007 15:15:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:50 GMT