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

Ben Laurie <benl@google.com> Mon, 10 August 2015 10:07 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 07EC51B33F4 for <trans@ietfa.amsl.com>; Mon, 10 Aug 2015 03:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 5.211
X-Spam-Level: *****
X-Spam-Status: Yes, score=5.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FB_CIALIS_LEO3=3.899, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 QohJY3Ghnkxp for <trans@ietfa.amsl.com>; Mon, 10 Aug 2015 03:07:04 -0700 (PDT)
Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205211B33F3 for <trans@ietf.org>; Mon, 10 Aug 2015 03:07:03 -0700 (PDT)
Received: by ykdt205 with SMTP id t205so54726991ykd.1 for <trans@ietf.org>; Mon, 10 Aug 2015 03:07:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=ibl6cjOrRp3MqFsuBBgHbudv40oIOuPuDx+mmf18LEw=; b=SRyHiMdgvelOSJhRz+ah5pLxuc/maLKvjzBjlchV4ZfmenRb84BHYQtiyoFarIAbHf HK6QBC7LOqEkyTh1YmZRqYZxHQqSa12aYU+e7qAwpre5bIsVVbsWzVoZswaXGX+sAipL IC2FLxLwznk4Kv7ff9MkPTaW+PAdVEmq/WihnjDNcs2npLrW7pxh8ki3Amj0gasWsn3b mNhQjzKmEup1r996tlZ2gGJwZDnGgapPAlqp7CLMtXRSxmu2KDQRbTH7hMlLjQDHKjhn g/WcjPrZ3eeJd6j4UCAJOw5kp/dvplIY+QscE4rZ/+xg0j6hC/8OrQDNGbLew0EqqYtg i5WQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=ibl6cjOrRp3MqFsuBBgHbudv40oIOuPuDx+mmf18LEw=; b=XbtiwjSMpp9BUyFp68MVtr06FpxRZ2Lsao85fgBRlXFuBCXETjfkXscuPOZq3Q5gCJ Yi5jq4q3ePxcav9syG/iiM5I8sIBqwmEL6v9QZyQgX/hjjVOnmCEdmv9AFidzQzbBuMO EK6tYsonXUUx7fCgoCeHFR1qSDENi2Y22s4cAJgVZabHwE/B2vZCo7aqCNXwvKqW49M7 IACrWsNuJl1Esd9iabO35dL4PWRilM264Ep6+yym3KsR44i6FuCT4Yf+g8jEjfl3q5ZV xunXc3DVCcjbfY7dMb7pTZ6tVMmtI/n0KTpe/q8OQBxRKmIFosX5cC3f6sP4oFzp/9w4 SPdw==
X-Gm-Message-State: ALoCoQlBe1KU+RygWsSQT/ekHTSNounWOC5FOifBTLbuEnTNKiKzozCqeomWUhjvEsUG/PGWIjgE
X-Received: by 10.170.56.8 with SMTP id 8mr4191313yky.115.1439201222397; Mon, 10 Aug 2015 03:07:02 -0700 (PDT)
MIME-Version: 1.0
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> <CABrd9SRXHH6FS=FeTp-fw8EHF5yeGEY=zu3rva+HCXZ0UQ9STA@mail.gmail.com> <1AD5EA0D-5E8C-4C1D-B32C-24CB9375C8F2@gmail.com>
In-Reply-To: <1AD5EA0D-5E8C-4C1D-B32C-24CB9375C8F2@gmail.com>
From: Ben Laurie <benl@google.com>
Date: Mon, 10 Aug 2015 10:06:52 +0000
Message-ID: <CABrd9SRLFScee0BS0QbQ+L0bL4JFM4mnkLvzsquo7x-tNnGg8Q@mail.gmail.com>
To: Bryan Ford <brynosaurus@gmail.com>
Content-Type: multipart/alternative; boundary="001a113946da9f970c051cf22536"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/EMaRParGVuSXcaWvjGjEWxXUkA8>
Cc: 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 10:07:08 -0000

On Sat, 8 Aug 2015 at 18:25 Bryan Ford <brynosaurus@gmail.com> wrote:

> On Aug 6, 2015, at 8:56 AM, Ben Laurie <benl@google.com> wrote:
>
> On Thu, 6 Aug 2015 at 10:17 Bryan Ford <brynosaurus@gmail.com> wrote:
>
> On Jul 24, 2015, at 1:09 PM, Ben Laurie <benl@google.com> wrote:
>> On Thu, 23 Jul 2015 at 23:27 Bryan Ford <brynosaurus@gmail.com> wrote:
>>
>> Second, the gossip approach can’t ensure that privacy-sensitive Web
>>> clients (who can’t or don’t want to reveal their whole browsing history to
>>> a Trusted Auditor) will ever actually be able “to detect misbehavior by CT
>>> logs”, if for example the misbehaving log’s private key is controlled by a
>>> MITM attacker between the Web client and the website the client thinks he
>>> is visiting.
>>>
>>
>> The intent of CT is not to enable clients to detect such behaviour -
>> rather, it is to enable the system as a whole to detect it.
>>
>>
>> Could you explain how “the system as a whole” detects such misbehavior in
>> the case of the state/ISP-level MITM attacker scenario?
>>
>
> The state or ISP must isolate all clients they attack forever to avoid
> detection. In practice, this does not generally seem to be possible.
>
>
>> As I see it, if the client/browser doesn’t opt-out of privacy by
>> gossiping his browsing history with a trusted auditor, then the client’s
>> *only* connection to the rest of the world, i.e., “the
>>
> system as a whole”, is through the “web server”, which may well be the
>> same kind of MITM attackers that have been known to subvert the CA system.
>> The client never gets to communicate to the rest of the system - i.e., the
>> legitimate CT log servers, auditors, or monitors - and so the client never
>> gets the opportunity to “compare notes” with the rest of the system.  And
>> the rest of the system (the legitimate log servers, auditors, and monitors)
>> never have the opportunity to learn from the client that the client saw a
>> MITM-attacked, forged set of CA certs, STHs, and SCTs.
>>
>
> This is correct, and seems to me to be correct for any system - if you can
> isolate your victim forever, you can show your own view of any system.
>
>
> To reiterate the key point I made in my response to Tom’s E-mail, this is
> not true of the multisignature-based STH signing I suggested.  Suppose for
> each CT log server there are (for example) 100 monitor servers widely
> distributed around the world, run by diverse companies, governments, etc.
> And suppose that any STH must be collectively signed by the log server and
> at least 51 of its monitor servers in order for clients to consider it
> valid.  Assume the victim user/browser is isolated behind a MITM attacker
> (call it Repressistan) who controls all the paths in and out of
> Repressistan and never lets the user physically enter or leave
> Repressistan.  Thus the user never has opportunity to do CT gossip via any
> path not controlled by the Repressistani Firewall.  In CT’s current design,
> Repressistan wins - gaining the ability to silently compromise the user
> forever - simply by Pwning one CA key and one log server key.  (Or maybe
> two if you require two SCTs per cert.)
>

> In the multisignature approach, Repressistan gains the ability to forge a
> STH for a “client-customized world view" only if Repressistan can also
> compromise more than 50 monitors of a compromised log server’s collective
> signing pool.  Every valid, client-verifiable STH signature ensures to the
> client not only that the log server’s key signed the STH but also that at
> least 51 monitor servers also witnessed it (even if those monitors are
> doing no checking at all other than saying “I saw it”).  Repressistan can
> no longer forge a valid (above-threshold) STH signature without an
> inconceivably massive collusion or security breach.  Repressistan still
> simply prevent the user from communicating at all, of course, but loses the
> ability either to silently compromise the connection or silently evade
> detection.  And the client need not risk its privacy via gossip in any way
> to receive this protection.
>

Clearly its a numbers game - there's always some threshold at which we can
claim that the required compromise is inconceivable.

We could make the existing scheme equally inconceivable by requiring 51
SCTs, which would also eliminate the need for gossip, according to you.

The problem I have with this idea is that if we eliminate gossip, then we
eliminate the possibility of detecting this compromise.

So, then the question is: what level of certainty do we need to be sure we
don't need gossip? I don't know how to answer that question. I do not find
it inconceivable, for example, that a consortium of governments could
compromise 51 out of 100 monitors.

Dropping gossip reduces the cost of compromise. Yes, if you can isolate a
client forever, then you can make gossip fail to detect compromise.
However, one slip and the cat is out of the bag, and the attacker's
expensive log(s) are no longer useful to them. That's a high price to pay
for a single attack.

That said, if you want some kind of consensus signature scheme for STHs,
there's no reason that couldn't live alongside other mechanisms.

I don't buy that it is a replacement for gossip, though.

BTW, seems to me you don't need >50% as your threshold - any signatures on
inconsistent STHs are an indication of badness, so if you assume monitors
are mostly honest and talk to each other, lower thresholds would also work.



> Suppose, for example, it ever so happens that a single company ends up
>>> running both a log server and a [sub-]CA, and keeps both in the same
>>> poorly-protected safe.  If an attacker can steal those two private keys,
>>> then the attacker can silently MITM any CT-aware client all it wants, by
>>> producing all the [non-EV] certificates it needs with a valid SCT, valid
>>> STH inclusion proofs in a fake log, etc.
>>>
>>
>> Chrome's policy would require the subversion of at least two logs to
>> achieve this, but for the sake of argument, I'll concede that.
>>
>>
>> I thought you were requiring CAs to have multiple SCTs only for EV
>> certificates, no?  What if the attacker is happy to MITM attack the user
>> with a non-EV certificate and forego showing the user the “green bar”?  Are
>> you assuming that users will stop using the connection if they don’t see
>> the green bar?
>>
>
> Not at all. EV certificates are our first step for CT.
>
>
>> Or are you saying (contrary to my prior understanding) that Chrome
>> requires *all* CT certs to have multiple SCTs signed by different log
>> servers?
>>
>
> Chrome makes no requirement on "CT certs", only on EV certs. But in the
> long run, the intention is to require CT for all certs.
>
>
> But what does “requiring CT” mean in terms of the number of SCTs a given
> cert (EV or non-EV) will be “required” to have?  What do you see as
> reasonable numbers there, for the near term and long term?
>

Chrome's current policy is here:
http://www.chromium.org/Home/chromium-security/root-ca-policy/EVCTPlanMay2015edition.pdf
.

We don't have any plans to change those numbers at present.


>
> With the multi-SCT approach, the amount of bandwidth consumed during TLS
>> negotiation with every CT-supporting website increases linearly with n.
>> With the scalable multisignature approach, n can increase to arbitrarily
>> large size - a hundred, a thousand if needed - e.g., including all the
>> public auditors, monitors, etc. - without any increase in the size of
>> certificates, number of SCTs attached, or ultimately the bandwidth/latency
>> overhead during TLS negotiation.
>>
>
> To be clear, you are proposing that instead of n logs with 1 signer each,
> we have 1 log with n signers?
>
>
> Possibly but not necessarily.  I envision n logs with m signers each,
> where say 1 <= n <= 10, but 10 <= m <= 1000.  (And different log servers
> need not have the same signers, or even the same number of signers.)
>
> That seems unwise to me. You then have a SPOF for the whole network.
>
>
> If a single log server cannot sign anything without it being witnessed and
> validated by 10, 100, or 1000 signers, how is it a SPOF?
>

The log itself has to be running - nextra signers do not improve its
availability.

 Again, I’m not saying n should be 1 - there are good reasons we might
> still want n to be greater than 1.  But if each log server can’t produce a
> valid STH without the active participation of a quorum of its m signers,
> and a reasonable number of those co-signers at least do minimal checking to
> ensure that the log server is behaving like a log (e.g., never signing two
> STHs with the same sequence number), then there’s a lot less a misbehaving
> log server - or an attacker who compromises that log server’s key - can do
> with it.
>

Its actually legal (and, in fact required, sometimes) to sign two STHs with
the same sequence number.

That aside, I do not disagree with the core idea. I wonder about its
practicality. For example, currently we require STHs to be produced on a
regular basis, which is necessary to ensure good behaviour. If we went to a
multi-signing approach, and an STH was not produced on time, who would we
blame? What would we do about that, in practice? Seems to me everyone
involved could point fingers at everyone else. How would you address that?


>
> But clearly each log could have more than one signer, but still have
> multiple logs. Then the question is: where is the trade off between number
> of logs and number of signers, bearing in mind that more than one signer
> introduces substantial complication.
>
>
> As I pointed out before, the problem with the current model is that adding
> log servers *decreases* security, at least in certain realistic attack
> scenarios, by giving the attacker more possible log server targets to
> compromise.  Weakest-link security, just as in the current CA system.
>

The whole point is to detect such compromises. Our ability to detect is
unaffected by the number of log servers.



>  Whereas increasing m, the number of signers per log server, can only
> increase security, assuming the multi-signing protocol/crypto itself isn’t
> broken.
>

Aside from my problem above, at least one other obvious issue with
increasing the number of signers, is you also increase latency (I suspect)
and decrease reliability.


>
> B
>