Re: [Ilc] Clarifications and thoughts purpose of ILC list

David Mazieres <dm-list-ietf-ilc@scs.stanford.edu> Tue, 28 February 2017 02:22 UTC

Return-Path: <dm-list-ietf-ilc@scs.stanford.edu>
X-Original-To: ilc@ietfa.amsl.com
Delivered-To: ilc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6146129498 for <ilc@ietfa.amsl.com>; Mon, 27 Feb 2017 18:22:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bZaOXqA5MVcf for <ilc@ietfa.amsl.com>; Mon, 27 Feb 2017 18:22:38 -0800 (PST)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485641293F0 for <ilc@ietf.org>; Mon, 27 Feb 2017 18:22:38 -0800 (PST)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v1S2MbFY062648; Mon, 27 Feb 2017 18:22:37 -0800 (PST)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1S2MZLp050269; Mon, 27 Feb 2017 18:22:35 -0800 (PST)
From: David Mazieres <dm-list-ietf-ilc@scs.stanford.edu>
To: Ben Laurie <ben@links.org>
In-Reply-To: <CAG5KPzzEPmKLW06ZieDYDjwB=AmXb6HVp_7sY2Aa1aLbfLqbNg@mail.gmail.com>
References: <87bmu194rx.fsf@ta.scs.stanford.edu> <CAG5KPzxXu8yuBzg08hjf0aV9hOTgAsAPo_E1P6kLWKTcs76q=g@mail.gmail.com> <878towah6b.fsf@ta.scs.stanford.edu> <CAG5KPzx20aq3aLAh1snSK9kpUpMt=0QVODV-vd04EDBORU9c8A@mail.gmail.com> <87zihcbj75.fsf@ta.scs.stanford.edu> <CAG5KPzzEPmKLW06ZieDYDjwB=AmXb6HVp_7sY2Aa1aLbfLqbNg@mail.gmail.com>
Date: Mon, 27 Feb 2017 18:22:34 -0800
Message-ID: <87mvd79hqt.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/ilc/aF-U0uV0yyZsl81utw65GCbJKBI>
Cc: ilc@ietf.org
Subject: Re: [Ilc] Clarifications and thoughts purpose of ILC list
X-BeenThere: ilc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: David Mazieres expires 2017-05-28 PDT <mazieres-62nv4a86abah6e9wpewna72ybw@temporary-address.scs.stanford.edu>
List-Id: "Discussion of mechanisms and applications for Internet-level consensus." <ilc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ilc>, <mailto:ilc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ilc/>
List-Post: <mailto:ilc@ietf.org>
List-Help: <mailto:ilc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ilc>, <mailto:ilc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Feb 2017 02:22:40 -0000

Ben Laurie <ben@links.org> writes:

>> The canonical guide is of course the whitepaper, which is probably hard
>> to read:
>>
>>         https://www.stellar.org/papers/stellar-consensus-protocol.pdf
>>
>> Maybe the most accessible rendition right now is my Google tech talk:
>>
>>         http://www.scs.stanford.edu/~dm/20160606-scp-talk.pdf
>>         https://www.youtube.com/watch?v=vmwnhZmEZjc&feature=youtu.be
>
> OK, this was very helpful.
>
> I was struck by your remark that enumerating the set of bad things
> that might happen to you is exponential time. At least, I think you
> said that. That doesn't seem like a great security property.

I don't remember exactly what I said, but this is a general property of
threshold systems.  For example, in f-out-of-3f+1 PBFT, the number of
failure modes is going to be approximately (3f+1)!.  But that's okay
because there's a symmetry to it.  Similarly, if you say, "I'm
vulnerable if every bank at which I have deposits and 2/3 of the other
big banks act maliciously," that might be a reasonable policy even if
it's hard to enumerate all the subsets matching that criterion.

Another thing I might have said is that if you got a global snapshot of
arbitrary quorum slice choices and wanted to decide if there was quorum
intersection, that would be akin to deciding satisfiability (best known
algorithm exponential).  But A) quorum slices shouldn't be arbitrary,
and B) not all forks are bad from ever individual node's
perspective--the important thing is to avoid being forked from people
you consider important.

That said, the stellar-core sotware does have some options like
"--inferquorum", "--checkquorum", and "--graphquorum" that print a
sample quorum or show quorums based on actual history (which is
obviously much smaller than every hypothetical potential history).  Such
options are useful to spot-check one's intuition about policy, but they
aren't comprehensive.

>> My understanding of CT may be out of date, but I thought CT was a
>> disjunctive system, as in any log can vouch for a certificate.  As I
>> envision Internet-level consensus, you could insist on, say, 7 out of 10
>> log authorities signing off something that guarantees publication of the
>> certificate.
>
> In practice, this is how CT works - Chrome has a policy on what logs
> must be used, for example. Full details here:
> https://www.chromium.org/Home/chromium-security/certificate-transparency.
>
> Obviously, if you are Joe Random, you can insist on some other policy.
> But the world is unlikely to provide it for you.

What you say necessary for certificate transparency because CT has to
"fail open" in the sense that logging is required while auditing the
logs is optional.  That is absolutely the correct design for TLS
certificates right now.

However, there are other potential applications where auditing should be
mandatory.  If is, then it becomes possible for Joe Random to insist on
another policy.

Here's an example:  Suppose RedHat and Debian start keeping logs of
every package they release, including package revocation messages for
packages found to have a vulnerabilities after they are released.
Furthermore, RedHat and Debian collaborate on some Internet-level
consensus to guarantee that their logs are append only.  Now suppose Joe
Random doesn't trust either RedHat or Debian.  Fortunately, the EFF
unilaterally decides to participate in consensus to help validate these
package logs.  By trusting a conjunction of RedHat, Debian, and the EFF,
Joe Random can gain greater assurance that he is not installing some
secret Trojan package that wasn't part of a mainstream Debian or RedHat
release.

>> Well, in my ideal world the browser vendors would ship some reasonable
>> default, but if I'm paranoid, I can add the ACLU and EFF, etc.  More
>> importantly, it should not be a pure disjunction where any CA can issue
>> any certificate, but rather should require some threshold.  Here we are
>> veering into CT 2.0 territory, because that's not how certificates
>> currently work, but there are other transparency applications that could
>> use such a threshold model from the start.
>
> OK, I am up for some kind of pluggable "what is the consensus"
> infrastructure, but what you propose here is a major departure from
> how things work right now. Such departures are hard.

To be clear, the last thing I am arguing for is in any way holding back
or changing the current design and deployment of CT.  However, for other
applications with fewer legacy requirements, it would be possible to get
stronger consensus.  And if such a consensus infrastructure works out,
it might be something appealing to CT in the future, or maybe some
auditing facility implemented on top of CT.  That's what I mean by the
vague term "CT 2.0."

>> What consensus mechanism does Trillian plug into?  I had assumed
>> Trillian was what an individual authority would do, but I could probably
>> use some education about the bigger picture.
>
> You are correct that Trillian is infrastructure. My vision is that
> logs would log each other's tree heads. Obviously this is unlikely to
> be universal, so is in some way the dual of your quorum slices.

So again, without advocating actually changing current CT efforts, what
if at some point we wanted to standardize not just the logging of
certificates but their auditing.  The idea would be that if, say, Google
legitimately obtains a second certificate from a different CA such as
TurkTrust before their first certificate expires, they submit to the
audit infrastructure a message signed by their old key saying that this
was a valid second certificate.  Otherwise, the auditing facility flags
the new certificate in such a way that browser users get a nasty pop-up
saying "Either this domain has a new owner, or they lost their key, or
this is a MITM attack."

This would obviously be a very long-term project, but it could improve
security over the status quo, and by letting any organization replicate
the auditing process, would allow Joe Random to customize his choice of
trusted auditors to some conjunction of parties he trusts and the rest
of the world trusts.

David