Re: [Trans] Threat model outline, attack model

Ralph Holz <holz@net.in.tum.de> Sun, 28 September 2014 12:17 UTC

Return-Path: <holz@net.in.tum.de>
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 AA7821A1A78 for <trans@ietfa.amsl.com>; Sun, 28 Sep 2014 05:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level:
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 YxkUWXs-U6LY for <trans@ietfa.amsl.com>; Sun, 28 Sep 2014 05:17:43 -0700 (PDT)
Received: from smtp1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BD81A1A76 for <trans@ietf.org>; Sun, 28 Sep 2014 05:17:42 -0700 (PDT)
Received: from [192.168.178.34] (109.125.75.212.dynamic.cablesurf.de [109.125.75.212]) by mail.net.in.tum.de (Postfix) with ESMTPSA id A2CD919BD947; Sun, 28 Sep 2014 14:17:39 +0200 (CEST)
Message-ID: <5427FC62.2000207@net.in.tum.de>
Date: Sun, 28 Sep 2014 14:17:38 +0200
From: Ralph Holz <holz@net.in.tum.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Tao Effect <contact@taoeffect.com>, Matt Palmer <mpalmer@hezmatt.org>
References: <54173589.3000404@bbn.com> <CABrd9SRShqm1r-2ajbqD5w1s686ciyjcEvywsXZaapgmi57NsA@mail.gmail.com> <54242F8A.2080602@bbn.com> <CABrd9SSwAdv-mAgofNT6bMWky7q=bZhAaX=L4gZUQDkROQ-3ZA@mail.gmail.com> <54258AF0.7090602@bbn.com> <4842B04F-A058-4F3C-9DA3-F29735EC7570@taoeffect.com> <alpine.LFD.2.10.1409262236210.27616@bofh.nohats.ca> <FC4A18E2-A42C-472F-B9FE-2278BB5A0BBA@taoeffect.com> <CABrd9SQBuQO1wrv7s06aT-GGyeWmu2sFzJrH6a+t81aq-dei+w@mail.gmail.com> <77D4B290-D2C8-44D7-AF84-A0A1B91B9557@taoeffect.com> <20140927211940.GP28050@hezmatt.org> <FDC8E60C-4CB4-447D-8562-FDB7B755B0B4@taoeffect.com>
In-Reply-To: <FDC8E60C-4CB4-447D-8562-FDB7B755B0B4@taoeffect.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/he9xWuaVJbQ544FwJLfDvZ3h6v8
Cc: trans@ietf.org
Subject: Re: [Trans] Threat model outline, attack model
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: Sun, 28 Sep 2014 12:17:45 -0000

Hi,

> And using Jacob's numbers from here:
> 
> http://www.ietf.org/mail-archive/web/therightkey/current/msg00745.html

It is interesting that this rumour, which was started with the EFF's
talk at DEFCON years ago, is still perpetuated. It has been disputed
numerous times and is most likely inflated by at least a factor of 2.

* DFN is not a collection of many CAs, but of one CA whose RAs are
identified in intermediate certificates - they do not hold the private
keys corresponding to the latter, however. They even document this fact
publicly.

* The number of organisations in the Mozilla root store holding CA
certificates is below 100, although about 60 are waiting for inclusion.
The number of root certificates is higher, but that is because many
organisations operate under several brand names and use different root
certs for different purposes (most notably EV).

* That leaves us with an undisclosed number of intermediate certificates
issued by CAs. Some of these may indicate subordinate CAs. This is a
problem as browsers often cache such certs for later use (once trusted,
always trusted). Mozilla has thus made it an obligation for CAs to
disclose their subordinate CAs if they are not identical to the "mother
organisation".

The latter factor gives huge leeway in the number of certs accepted by
browsers as root certs. But however you look at it, the number of such
certs will be comfortably below 1000 - anything from the 150+ root certs
in the Mozilla store up to a few hundred.

Applied to CT, these numbers matter even less if gossiping, monitoring
and auditing can be used. First, logs only accept a limited number of
CAs, as a anti-flooding protection. I'd love to hear what CAs plan here
- if their subordinates are eligible for acceptance by a log or not. And
second, the gossiping between logs and between clients has an important
effect: an attacker would have to compromise quite a few logs to make
sure his MITM is effective. Just requiring, say, 3 SCTs in a handshake
would already result in considerable work for the attacker (I know the
current number is 2, though). There is no need for clients to cooperate
with 1000 logs.

That's my understanding at least - happy to hear comments.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universit√§t M√ľnchen
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18010
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF