Unbelievable! - mozilla.dev.tech.crypto

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
mozilla.dev.tech.crypto
Message from discussion Unbelievable!
Path: g2news2.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.mozilla.org!news.mozilla.org.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 23 Dec 2008 15:12:41 -0600
Date: Tue, 23 Dec 2008 22:12:21 +0100
From: Ian G <i...@iang.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB;
	rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1
MIME-Version: 1.0
To: mozilla's crypto code discussion list <dev-tech-cry...@lists.mozilla.org>
Subject: Re: Unbelievable!
References: <hrSdnQm2FfNOjs3UnZ2dnUVZ_jWdnZ2d@mozilla.org>	<mailman.937.1229996305.4225.dev-tech-crypto@lists.mozilla.org>	<N_idnTz82u653s3UnZ2dnUVZ_rfinZ2d@mozilla.org>	<mailman.938.1229997198.4225.dev-tech-crypto@lists.mozilla.org>	<TKqdnYFmHqc9783UnZ2dnUVZ_h6dnZ2d@mozilla.org>	<tYidnaZDl8NaIs3UnZ2dnUVZ_qninZ2d@mozilla.org>	<wZidnQG-Jfvfec3UnZ2dnUVZ_qzinZ2d@mozilla.org>	<495106EF.2020109@mozilla.org>	<mailman.982.1230056263.4225.dev-tech-crypto@lists.mozilla.org>	<PO-dnWzRYIjPrMzUnZ2dnUVZ_vCdnZ2d@mozilla.org>
	<6b9359640812231123r5861afa3h3ffd3c4549a18a59@mail.gmail.com>
In-Reply-To: <6b9359640812231123r5861afa3h3ffd3c4549a18a59@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Reply-To: mozilla's crypto code discussion list
	<dev-tech-cry...@lists.mozilla.org>
Newsgroups: mozilla.dev.tech.crypto
Message-ID: <mailman.994.1230066761.4225.dev-tech-cry...@lists.mozilla.org>
Lines: 100
NNTP-Posting-Host: 63.245.208.166

On 23/12/08 20:23, Kyle Hamilton wrote:
> On Tue, Dec 23, 2008 at 10:43 AM, Frank Hecker
> <hec...@mozillafoundation.org>  wrote:
>> I've asked Robin Alden of Comodo to make an accounting regarding these two
>> issues. I don't expect to see that immediately (i.e., in the next day or
>> two), though I also don't expect to wait a month for it (as Kyle is
>> concerned about).
>
> Actually, I think it's very important that the accounting include this:
>
> for each name (not just certificate, but name in
> subjectAlternativeNames) that has been certified, a connection to the
> TLS ports should be made, and the certificate presented by the site
> compared against the certificate that Comodo issued.  This obviously
> won't be a complete verification, but it should give a start to see
> how widespread the problem is.


Um.  Some questions... On what basis are we asking for this "accounting" ?

Is there a criteria that calls for public breach accounting?  Perhaps 
Mozilla needs to add it?  Most of the criteria call for revocation when 
a false cert has been issued, and that seems to have been met right now.

Also, some of the process might instead rest with Comodo's external 
auditor or its internal audit process or its internal security process. 
  Perhaps in the next audit, there will be an examination of the 
remedial steps taken, to see if they conform to the security manual, etc.

There are some slippery slope aspects here.  If the framework for such 
"accounting" is outside Mozilla's area, then care might be needed. 
There could be confusion in role and liabilities.

It's nice if Mozilla were minded to do all the audit and security 
activities for all, but I'm not sure Frank has time ;)  OTOH, if we feel 
the need to usurp the CA's processes and the conventional audit 
relationship with an "accounting" then perhaps we need to also simplify 
some other processes?

Another aspect here is that the goal of any security or governance 
process is not to eliminate or stop all breaches.  The process is more 
about how you keep dangers to a minimum, deal with the breaches that do 
happen, and improve.


> I hate to say this, but this IS The Worst-Case Scenario.

Noooo.... With respect, I'd say worst case is that a root has been 
breached, and the Carders have got hold of it and are MITMing the major 
retail sites.  Damages!

Earlier, Frank used the language of "clear and present danger."

   * clear:   we can measure the costs of it, and cost of defences.
   * present: it is happening today, provably.
   * danger:  it can be shown capable of doing damage, at least in theory

Only the last one is shown.  It is a danger in that anyone relying on a 
cert wrongly issued could be harmed.  But it hasn't actually caused 
anyone damages, and nobody has shown it to exist.

This situation is about as harmful as the average exploit demo.  In this 
particular case it was caught by an insider rather than by an outsider. 
  However, beyond that, the situation is already sealed in that Comodo 
have already taken the urgent triage steps to make sure nobody else gets 
one.


> A CA has
> gone rogue and issued certificates that violate its standards, and the
> standards of the root programs that it's a part of -- it is true that
> Comodo didn't /intend/ to go rogue, but it has, and we can't afford to
> let it damage the greater PKI.



This is no different to when Verisign got schnikered into issuing a 
couple of Microsoft certs.  No damages ever resulted.  The system worked 
as it was expected to, it seems.  Panic is not called for.


> Since every CA in the root store is
> treated the same, there is no differentiation between them -- and this
> means that Verisign and Comodo and Thawte and *every* CA share the
> same reputation.  If one goes rogue, it's exactly the same as if all
> of them have gone rogue, in the eye of the end-user.

...

> THIS is why I want to see greater differentiation in the browser
> chrome between CAs, so that one bad apple doesn't spoil the whole root
> barrel.  THIS is why the argument against changing the chrome (user
> convenience) fails.


Oh, on that, yes, strongly agree.  There's no trust without brand :)



iang
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
