Message from discussion Unbelievable!
NNTP-Posting-Date: Tue, 23 Dec 2008 15:12:41 -0600
X-Virus-Scanned: amavisd-new at mozilla.org
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
To: mozilla's crypto code discussion list <dev-tech-cry...@lists.mozilla.org>
Subject: Re: Unbelievable!
References: <hrSdnQm2FfNOjs3UnZ2dnUVZ_jWdnZ2d@mozilla.org> <email@example.com> <N_idnTz82u653s3UnZ2dnUVZ_rfinZ2d@mozilla.org> <firstname.lastname@example.org> <TKqdnYFmHqc9783UnZ2dnUVZ_h6dnZ2d@mozilla.org> <tYidnaZDl8NaIs3UnZ2dnUVZ_qninZ2d@mozilla.org> <wZidnQG-Jfvfec3UnZ2dnUVZ_qzinZ2d@mozilla.org> <495106EF.email@example.com> <firstname.lastname@example.org> <PO-dnWzRYIjPrMzUnZ2dnUVZ_vCdnZ2d@mozilla.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Reply-To: mozilla's crypto code discussion list
List-Id: mozilla's crypto code discussion list
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
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
> 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 :)