[Trans] What's the load on a CT log?

Ben Laurie <benl@google.com> Thu, 13 March 2014 16:06 UTC

Return-Path: <benl@google.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 382A31A0A18 for <trans@ietfa.amsl.com>; Thu, 13 Mar 2014 09:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.526
X-Spam-Level:
X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=unavailable
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 ExmBSFlV09_X for <trans@ietfa.amsl.com>; Thu, 13 Mar 2014 09:06:13 -0700 (PDT)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7541A1A044B for <trans@ietf.org>; Thu, 13 Mar 2014 09:06:13 -0700 (PDT)
Received: by mail-ve0-f171.google.com with SMTP id cz12so1313047veb.2 for <trans@ietf.org>; Thu, 13 Mar 2014 09:06:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jkg2f6Uv1RaAUIRNkS0aCZt6bmt0bCTl/SBuiAzvWWw=; b=EIKav2oW2n5G6TX9rdSm9PnsmXrBxTlm5jNf00iVWl9wwAp+isMcVhkxjLyDmzSyMr uqiOSZW66w661Byds74GWr0NV18jFJLV8Y+mgq3Wk2ndjYsSAZOX2I5eLT+6IZbSI0tP A/UgXuGOy+OmPuH/cgPLwU8zkoawDlsO/wDUq6VNxt0XtPgOOBA/tW9VAg26VTprvVPi Y/Me8dIMRcO3wWb7XvK3oHwijoH+6liTNp5+FgqFnFLHjuT+ZMAzLec95XO25Az0xI4x uH8cd4QSAdG/PsfpvS3v4M+0etGD6nWRfMNmYpfQhgFqDxTK2PflBzWa6IIAc13eMdUp qBCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=jkg2f6Uv1RaAUIRNkS0aCZt6bmt0bCTl/SBuiAzvWWw=; b=QqgaL4GjiFTJsKu7UnqoBUXdvB0soBKLy83b+IStGQFx3x0ZWhpBi7LARnxtKcefcY mgED+lXIknah9r9q5+XQxLzFE0zkWPm4E6lljIId6U+rS8XZ4XCfemXljIxnP57ION87 Gp/R76uvP3CUSksG6tb5HBeFtk6rJxC52DomjT4jlsTm00OXZr0H5FMRAr/9uqDGnlTq bIg0MEjOx92SRw9hGq98nhFT2bAFvydXAyh74hgxxZqo95SKPk0D5cLw7rY/xCYf4nOJ Yt/UMkI/4T1NHdxkXHE0LcZXo41N/tDSmo0IP3FQ9Hjp8+7Wu6aMghgUKjqHjQb4YZTW 1ylw==
X-Gm-Message-State: ALoCoQnbELxT6fUs5+oBcHvr02pFWJOdELOAU9Gj1iCeWsbtDHO0JKLVpll6gr73XzsFjzTgJE8KkJjwOE/CnCiAD+bqGAH6sNJ/7mpWcRLKPTKFdm5/n7LKsklFxhaa0UM498nnn0fbsO2AaUQMv4WmWZVDouev2UvMgYS0JVx+nSgg1chNLZ+HWokZJX3AaCDImieWTuW0
MIME-Version: 1.0
X-Received: by 10.220.69.133 with SMTP id z5mr139733vci.49.1394726766692; Thu, 13 Mar 2014 09:06:06 -0700 (PDT)
Received: by 10.52.230.105 with HTTP; Thu, 13 Mar 2014 09:06:06 -0700 (PDT)
Date: Thu, 13 Mar 2014 16:06:06 +0000
Message-ID: <CABrd9SR4G6hEUEW9yHLyS40Km3+jmK8K-tEjLMjLqN1M+Go_=g@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: "trans@ietf.org" <trans@ietf.org>, "therightkey@ietf.org" <therightkey@ietf.org>, "certificate-transparency@googlegroups.com" <certificate-transparency@googlegroups.com>, CABFPub <public@cabforum.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/FW9GCI-tQW7Ld9NWz-iUlIgI8NU
Subject: [Trans] What's the load on a CT log?
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: <http://www.ietf.org/mail-archive/web/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: Thu, 13 Mar 2014 16:06:19 -0000

Several people have asked me this recently. Here's a nice way to estimate load.

Let's assume a single log that takes all the load.

Firstly, we see about 5,000 new certificates a day, so that's around
0.06 new certificates per second. Clearly a trivial load.

Next is load from audit (i.e. from browsers that wish to validate SCTs
accompanying certificates they see). Given some assumptions, we can
calculate the load from audit.

* Clients cache audit results.

* There are approximately b = 2.5B browsers in the world
(http://www.internetworldstats.com/stats.htm).

* The average user visits w = 89 websites a month
(http://www.creditloan.com/blog/how-the-world-spends-its-time-online/
quoting a Nielsen report). Assume these are all TLS sites.

* Assume a certificate lifetime of l = 12 months.

So, each user sees w / l new certificates a month. Each new
certificate needs to be audited, which means in practice, three web
operations (fetch STH, fetch STH consistency proof, fetch SCT
inclusion proof) - it might be a good idea to create a new API to do
all three in one go.

So, total average load is 3 * b * w / l ~ 20,000 web fetches per
second. If we optimise the API we can get that down to 7,000 qps. Each
query (in the optimised case) would be around 3 kB, which gives a
bandwidth of around 150 kb/s.

Monitors add extra load, but should only be at around the new
certificate rate - i.e. ~ .06 * number of monitors fetches per second.

IMO, this is achievable on a single machine (modulo reliability), with
some care. Clearly not a vast farm, however its done.

In practice, no one log would have to take this full load, this is a
worst case analysis.