Re: ACTION-240 :TLS errors...

I would also recommend:

http://cups.cs.cmu.edu/soups/2005/2005proceedings/p13-garfinkel.pdf

to see it's use in a context (email), and get a sense of its strengths and 
weaknesses (not so hot for bootstrapping attacks, but great for the 
continuity thing it's named after). 

          Mez



public-wsc-wg-request@w3.org wrote on 07/19/2007 11:39:00 AM:

> [image removed] 
> 
> Re: ACTION-240 :TLS errors...
> 
> Serge Egelman 
> 
> to:
> 
> Dan Schutzer
> 
> 07/19/2007 11:44 AM
> 
> Sent by:
> 
> public-wsc-wg-request@w3.org
> 
> Cc:
> 
> "'Johnathan Nightingale'", "'W3C WSC Public'"
> 
> 
> 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
> */
>