- From: Serge Egelman <egelman@cs.cmu.edu>
- Date: Thu, 19 Jul 2007 11:39:00 -0400
- To: Dan Schutzer <dan.schutzer@fstc.org>
- CC: "'Johnathan Nightingale'" <johnath@mozilla.com>, "'W3C WSC Public'" <public-wsc-wg@w3.org>
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