Re: ACTION-240 :TLS errors...

Yup, we all think it's a great idea.

Serge, would you be up to drafting something, either as a standalone 
proposal, or a change/extension to one of the existing ones?  (I'm 
blanking out on exactly where it would fit. What is a secure page talks 
more about the confidentiality than the identity, and this is more about 
identity. But Page Info relegates it to secondary SCI. Identity Signal? 
Security Protocol Error Presentation? )






Re: ACTION-240 :TLS errors...

Serge Egelman 
to:
Johnathan Nightingale
07/18/2007 10:14 AM


Sent by:
public-wsc-wg-request@w3.org
Cc:
W3C WSC Public








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
*/