Re: ACTION-240 :TLS errors...

I haven't done any work on it.  But this might help:

http://portal.acm.org/citation.cfm?id=1073003

Read the references as well, if you're not familiar with them.  I'm sure
you can download the paper elsewhere if you google for it.

serge


Dan Schutzer wrote:
> 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:41:01 UTC