Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct

Rob Stradling <rob.stradling@comodo.com> Mon, 10 August 2015 21:05 UTC

Return-Path: <rob.stradling@comodo.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F5C1B3C60 for <trans@ietfa.amsl.com>; Mon, 10 Aug 2015 14:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.579
X-Spam-Level:
X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAorbFiGru-I for <trans@ietfa.amsl.com>; Mon, 10 Aug 2015 14:05:37 -0700 (PDT)
Received: from mmextmx2.mcr.colo.comodoca.net (mail1.comodoca.com [91.209.196.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD341B3E88 for <trans@ietf.org>; Mon, 10 Aug 2015 14:05:36 -0700 (PDT)
Received: (qmail 4780 invoked by uid 1004); 10 Aug 2015 21:05:35 -0000
Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 10 Aug 2015 22:05:35 +0100
Received: (qmail 28673 invoked by uid 1000); 10 Aug 2015 21:05:35 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 10 Aug 2015 22:05:35 +0100
From: Rob Stradling <rob.stradling@comodo.com>
To: Ben Laurie <benl@google.com>, Bryan Ford <brynosaurus@gmail.com>, Tom Ritter <tom@ritter.vg>
References: <mailman.3884.1437667800.3631.trans@ietf.org><6E6EF479-66BE-4EBE-956C-22009BCED863@gmail.com><CABrd9SRG-SQtADhS=hee_Zf4vzMETyZOYtqg5Xp82Dq70C0puQ@mail.gmail.com><7BE2DAF1-6D52-4E6C-A00D-0F91B74B5028@gmail.com><CA+cU71mQK79=dVOOq14fOtG_QdeEUujRNbLN0y+0RchCOvOW6w@mail.gmail.com><F6F1FBBD-2471-4A66-A475-7B2F0B2C47A9@gmail.com> <CABrd9SQ2jOVyjB9aMiphVQMaZeyuC+5bhw9hDKz6kSET6xFUeQ@mail.gmail.com>
Message-ID: <55C9121E.4040107@comodo.com>
Date: Mon, 10 Aug 2015 22:05:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CABrd9SQ2jOVyjB9aMiphVQMaZeyuC+5bhw9hDKz6kSET6xFUeQ@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/3UeGdjfXvGGVf6zaClHONJUYvLA>
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2015 21:05:41 -0000

On 10/08/15 11:28, Ben Laurie wrote:
>
> On Sat, 8 Aug 2015 at 17:56 Bryan Ford <brynosaurus@gmail.com
> <mailto:brynosaurus@gmail.com>> wrote:
>
>     Hi Tom,
>
>>     On Aug 6, 2015, at 11:46 AM, Tom Ritter <tom@ritter.vg
>>     <mailto:tom@ritter.vg>> wrote:
<snip>
>>     The Comodo incident you reference, was that the mozilla.com
>>     <http://mozilla.com> cert in
>>     2008?  That was someone just trying a RA portal and getting a cert:
>>     http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/
>
>>     Despite all the effort to find such certs manually, via MEKAI,
>>     Perspectives, Convergence, Cert Patrol, and others - I'm not aware of
>>     anyone ever catching a CA-signed misissued cert manually.
>
>     I think it was the March 2011 incident, where a hacker was able to
>     obtain fraudulent certificates through Comodo and then apparently
>     attempted to use at least one of them, for ‘login.yahoo.com
>     <http://login.yahoo.com>’, in some way:
>     https://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
>     Comodo’s report and the other information I found don’t make it
>     clear exactly in what way the login.yahoo.com
>     <http://login.yahoo.com> cert was “seen live on the Internet” -
>     perhaps it was Google pinning as well if Google was pinning Yahoo’s
>     certs at that time (were they?), or perhaps it was manual
>     forensics.  Perhaps you or someone else has better information about
>     this.  But this is all incidental: it’s great that Google pinning
>     has caught a lot of incidents, but nobody seems to be saying that
>     means Google pinning is the best/final solution.
>
>
> In this case, though, CT would have caught the mis-issue.

Had we (Comodo) been submitting all certs to CT logs at that time, then 
yes, CT would have caught these mis-issues.

Had Chrome been doing certificate pinning at that time (which I don't 
think it was, given that 
https://www.imperialviolet.org/2011/05/04/pinning.html is dated a couple 
of months later), it would have caught these mis-issues too, if any 
Chrome users had actually been exposed to any of these certs "live on 
the Internet".

The "seen live on the Internet" claim: Within a few hours of us noticing 
the mis-issuances, we'd analyzed our webserver logs looking for activity 
on the compromised account and we'd spotted some IP addresses allocated 
to Iran.  One of my colleagues did a port 443 scan across the relevant 
IP subnets and found a server that was sending that login.yahoo.com 
cert.  IIRC, that server wasn't up for long.

Incidentally, this is pretty fair summary of the incident:
https://www.chromium.org/Home/chromium-security/root-ca-policy
"In March of 2011, Comodo issued fraudulent certs for a number of 
well-known internet sites including Microsoft, Yahoo and Google. This 
was not due to a compromise at Comodo, but rather at an authorized 
Registration Authority operating on Comodo’s behalf. In that case, 
Comodo immediately spotted the mis-issuance, revoked the certificates, 
notified the affected parties, and made a full and public disclosure of 
what had happened, albeit a week after the event. While the compromise 
itself cannot be minimized, Comodo mostly acted in a manner consistent 
with the trust placed in them as a Root CA (earlier disclosure would 
have been better)."

My one complaint is the "mostly...earlier disclosure would have been 
better" part.  We wanted to disclose ASAP, but one of the browser 
providers said they needed 9 days to produce and test patches.  That may 
sound implausible now, but remember that this was before any of the 
browsers had introduced their certificate blacklisting mechanisms (i.e. 
Google's CRLSets, Microsoft's disallowed.stl, etc).

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online