Re: [Trans] Threat model outline, attack model

Tao Effect <contact@taoeffect.com> Sun, 28 September 2014 17:04 UTC

Return-Path: <contact@taoeffect.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 5B2361A1B79 for <trans@ietfa.amsl.com>; Sun, 28 Sep 2014 10:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
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 tGg99_p5bd9q for <trans@ietfa.amsl.com>; Sun, 28 Sep 2014 10:04:43 -0700 (PDT)
Received: from homiemail-a8.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 051681A1B75 for <trans@ietf.org>; Sun, 28 Sep 2014 10:04:43 -0700 (PDT)
Received: from homiemail-a8.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a8.g.dreamhost.com (Postfix) with ESMTP id CACF0D22082; Sun, 28 Sep 2014 10:04:42 -0700 (PDT)
Received: from [192.168.42.78] (50-0-138-93.dsl.dynamic.sonic.net [50.0.138.93]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a8.g.dreamhost.com (Postfix) with ESMTPSA id 3123AD22070; Sun, 28 Sep 2014 10:04:42 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_B79861CB-3F2B-43BF-BA55-488113AF38DA"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Pgp-Agent: GPGMail 2.1 (f76fd85)
From: Tao Effect <contact@taoeffect.com>
In-Reply-To: <8C9EE7D9-32B7-4DF1-86B3-1E6B00C70BA6@taoeffect.com>
Date: Sun, 28 Sep 2014 10:04:42 -0700
X-Mao-Original-Outgoing-Id: 433616682.323777-63a16189c882111be4de79982247f562
Message-Id: <1B481479-7533-4D19-AEEE-49FE12C6AB2D@taoeffect.com>
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> <5427FC62.2000207@net.in.tum.de> <8C9EE7D9-32B7-4DF1-86B3-1E6B00C70BA6@taoeffect.com>
To: Tao Effect Support <contact@taoeffect.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/qGudh8Hm8QeCBzrDOYhdua4Mi0g
Cc: Ralph Holz <holz@net.in.tum.de>, Matt Palmer <mpalmer@hezmatt.org>, 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 17:04:44 -0000

On Sep 28, 2014, at 10:01 AM, Tao Effect <contact@taoeffect.com> wrote:
> 
>> There is no need for clients to cooperate with 1000 logs.
> 
> 
> Well, if they want to know for certain that they weren't MITM'd, they're going to have to search up to a 1000 logs (or several hundred, whatever the number happens to be).

Erm, sorry, not "for certain", because even if they did scan those logs for inappropriate certs, that still won't tell them whether or not the certificate is fraudulent for two reasons:

1. Only the website owner determines whether the certificate is actually fraudulent. Clients cannot determine this with CT, no matter how much gossip they do, nor how many logs they query.

2. Similar to #1 but not identical is the possibility that a revoked certificate was used to MITM.

Kind regards,
Greg Slepak

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

On Sep 28, 2014, at 10:01 AM, Tao Effect <contact@taoeffect.com> wrote:

> Dear Ralph,
> 
> On Sep 28, 2014, at 5:17 AM, Ralph Holz <holz@net.in.tum.de> wrote:
> 
>> 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.
> 
> Thanks for clarifying some of this!
> 
> This is just Mozilla, however. Even if we go by your numbers, we still need to do a union on the certs accepted by other browsers, and other operating systems.
> 
> Do you happen to have numbers for that too?
> 
>> Just requiring, say, 3 SCTs in a handshake
>> would already result in considerable work for the attacker
> 
> Yes, I think that would improve things.
> 
>> (I know the current number is 2, though).
> 
> 
> The current number is 1 according to the most recent version of the RFC I could find (bis-04):
> 
> https://raw.githubusercontent.com/google/certificate-transparency-rfcs/master/draft-ietf-trans-rfc6962-bis-04.txt
> 
>> There is no need for clients to cooperate with 1000 logs.
> 
> 
> Well, if they want to know for certain that they weren't MITM'd, they're going to have to search up to a 1000 logs (or several hundred, whatever the number happens to be).
> 
> Kind regards,
> Greg Slepak
> 
> --
> Please do not email me anything that you are not comfortable also sharing with the NSA.
> 
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans