Re: [Trans] Threat model outline, attack model

Ben Laurie <benl@google.com> Sat, 27 September 2014 11:53 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 388661A1AEC for <trans@ietfa.amsl.com>; Sat, 27 Sep 2014 04:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.266
X-Spam-Level:
X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.786, 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 pLB1klVX1164 for <trans@ietfa.amsl.com>; Sat, 27 Sep 2014 04:53:32 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C041A1AEA for <trans@ietf.org>; Sat, 27 Sep 2014 04:53:32 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id rd18so12059329iec.19 for <trans@ietf.org>; Sat, 27 Sep 2014 04:53:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RZm59iCRiwUvMQDEJQbcza5ZvfzK9I49BBju7kPk+tk=; b=BB+vkc7L0PJZsrGTpZxFQhF5F240VI0pNKDA24R1BBfF3TprjONmhra3NAkzNzaAg/ cbAOvluPiFqsBiXrJ+QT4x82YEOq3OMnezhCWtgBvu6MT/QoDo95LGlTMHLL3CbljufY yAVz1/IBa6QUqvm+wLsUkJSXbsX8Xtb/10gYrJTRFP8nANzVYQ4wd0RGSmoxVLDb1+Jm 6+eRaWN5i5lR3MvBVnl5FngAySIY6GvJEsRChdiAJooAjxS09L4U9N7XTsrFzcZJsehP /AFIsFuecZ88sbtcsO9vp8nwMUMEWPSUUaZTbCMuoONa/pmrW6r7B1UWDmdkkJq8hF5F dlpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RZm59iCRiwUvMQDEJQbcza5ZvfzK9I49BBju7kPk+tk=; b=bDb3LUX1VL0qjmi6dC/0kZ45qZx+2EiTyRDSjKDSTG8SLblN6/LnVKsEwpXxpxpgoD fUrITKHIpflxZnTeYE3WP0Nkzvw5nSEQ6OwGHlLpBmCsEwH9KX8vLppge28tyegK2SC6 p0X+B/FMaImLtVpeykZ866bRccvw+aCULeOs8s8tx1jAdiEz0AOH8cw+LDrK6TbJW2WZ k9of2duHZ2zGl7UajEgQ3mZGzJWzFUPIYW8dhjBxFizDXZAqpKsgDROPaovo1LCmd+/P jfAAm9LOoNJjJJW9uMFZHo2D6Xhy7cvVWhuaODwZrC4rrC9ucAxKtEm/JnD+LDhmD20v b7WA==
X-Gm-Message-State: ALoCoQlVTbxp/llQHOplEvd54Rw70q+YK9iZWfnkZnzM0931DAGhpVmS2vD3j3QXejNsDEV8//Cg
MIME-Version: 1.0
X-Received: by 10.50.72.73 with SMTP id b9mr4328788igv.0.1411818811766; Sat, 27 Sep 2014 04:53:31 -0700 (PDT)
Received: by 10.64.118.67 with HTTP; Sat, 27 Sep 2014 04:53:31 -0700 (PDT)
In-Reply-To: <FC4A18E2-A42C-472F-B9FE-2278BB5A0BBA@taoeffect.com>
References: <5411E511.1040605@bbn.com> <CABrd9STmog8-JZCg9Tfv_ToUswY=9LBcZAPQM2cqUVcO0dhAnQ@mail.gmail.com> <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>
Date: Sat, 27 Sep 2014 12:53:31 +0100
Message-ID: <CABrd9SQBuQO1wrv7s06aT-GGyeWmu2sFzJrH6a+t81aq-dei+w@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Tao Effect <contact@taoeffect.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/GY_D2wVwkElY8F_x8Ted34XL_iI
Cc: Paul Wouters <paul@nohats.ca>, "trans@ietf.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: Sat, 27 Sep 2014 11:53:34 -0000

On 27 September 2014 06:05, Tao Effect <contact@taoeffect.com> wrote:
> Dear Paul,
>
> On Sep 26, 2014, at 7:38 PM, Paul Wouters <paul@nohats.ca> wrote:
>
> It would be even better it you would be part of the discussion here on
> the trans working group to ensure the gossip protocol is implemented
> in a way that is secure and useful to everyone, including yourself.
>
>
> That's very kind of you to invite me to the discussion, so I spent some time
> just now thinking about how to do gossip right.
>
> To start, I re-read the most recent document I have on gossip:
>
> http://www.ietf.org/proceedings/90/slides/slides-90-trans-2.pdf
>
> Then something occurred to me: for some reason, perhaps because of how
> complicated the details of CT are, I hadn't realized that I was wrong about
> something, that now seems obvious. In my blog post, I'd written:
>
> At its core, it introduces the concept of an append-only auditable log that
> is guaranteed to show the most recently issued SSL cert for any given domain
> (IF you’re able to ask it).

This is not a guarantee CT aims to provide, nor, as you illustrate
below, is it a particularly useful guarantee.

> That is actually not true (for Auditors).

Quite.

> So then I re-read parts of Steve's original post in this thread that I had
> skipped. Indeed, there it was in his "Notes", the same thing I just now
> realized (he really did a fantastic job):
>
> 1. If a CA submits the bogus certificate to logs, but these logs are not
> watched by a Monitor that is tracking the targeted Subject, CT will not
> mitigate a mis-issuance attack. It is not clear whether every Monitor MUST
> offer to track every Subject that requests its certificates be monitored.
> Absent such a guarantee, how do TLS clients and CAs know which set of
> Monitors will provide “sufficient” coverage. Unless these details are
> addressed, use of CT does not mitigation mis-issuance even when certificates
> are logged.

I agree that CT doesn't mitigate mis-issuance for subjects that do not
participate. On monitors and guarantees - anyone can run a monitor,
including, of course, the subjects themselves, so clearly there's no
barrier to participation for subjects who want to participate.

> For Auditors, it doesn't mitigate mis-issuance even for *the same* log.
> I.e., a rouge CA/log combo (let's just call them "Clogs" :P) is free to step
> in, create a fraudulent certificate, use it for MITM, and then restore the
> original, undetected even by Auditors that successfully gossip STHs! For the
> same log!
>
> The only ones who can stop this are Monitors, since they are able to request
> everything that's in the Clog and verify for themselves that there aren't
> any fraudulently issued certs.
>
> And this, my friends, is Game Over.
>
> I see no way that Monitors can save us here, even with successful gossip of
> STHs.
>
> To save us, Monitors would need to monitor *all* logs for *all* domains and
> somehow successfully get this information to people who are being attacked
> with a fraudulent certificate.
>
> Sorry, I tried, and in trying, I've realized that CT is more broken than I
> originally thought. I have no recommendations to give (except ones that
> you've heard already, and are likely "off topic" on this list).
>
> :-\
>
> 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
>