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

Ben Laurie <ben@links.org> Thu, 23 February 2017 22:38 UTC

Return-Path: <benlaurie@gmail.com>
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 DF19D129BB1 for <ilc@ietfa.amsl.com>; Thu, 23 Feb 2017 14:38:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pJolcZ8O-T9I for <ilc@ietfa.amsl.com>; Thu, 23 Feb 2017 14:38:00 -0800 (PST)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 78FFA129B9F for <ilc@ietf.org>; Thu, 23 Feb 2017 14:38:00 -0800 (PST)
Received: by mail-wr0-x230.google.com with SMTP id 89so2779601wrr.3 for <ilc@ietf.org>; Thu, 23 Feb 2017 14:38:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=N63VuiccjuyBwIU/7a7kT6tQvWcVblrbD6v3YfscwHY=; b=XKLy9HvPHCuRFjRIYFRc3CnmyG+Njb0Tx5t7SotmLZRJ+uYwODD3otg4jvPn8e41CP lKcefWUQjEmuX4W+LMjCMVXG63UHrtDZqTeR58sE8hutd10zFIrXKiX7ociZ5i085OaG M4lfdbM07E4DgwxlnFQD8zBHCi2ooEZEuORp2Z9XwGoHtMQSgoO7VipV3mbl0u1Mknnc tGKQKMciGAnBQ23P5QLbYFVFBTK5hglxoZkJwuw0JwULpuTTvFRWtCA72dkXqXjEb4XG ax1SA02cOVpcneJo1kZlTUxBFLiCvrQ7jxd6v+U5zuDLugAHgMhzVqwFNydc3U8vdUwa nL3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=N63VuiccjuyBwIU/7a7kT6tQvWcVblrbD6v3YfscwHY=; b=BIJBHiGdrTCAPHFI0lKejwhmgCYdagRYu1YsM2m0o2G2n3QCb3dRC1r9wPzHooSJVU 6dipw55xwCV3FSmMeXlORYNty6/B571fINQyCbI4M5QezILTtITugdWVEcnlA7w/OVG9 Ak6cX0wM4+ESG+yWzndZKcyrvlzIuW4q1Gbn17WnVgWLXHsw0gTIMYs3+pEgDZQrnH41 a3iOGxHg8rBaOHG7eWzpUYtrGSm3dBXwAX85ibbFm7GOCXoI9X2D7O9ugWXOd3472B94 6bbk8D/zecT+DONCa7seo7GMsaCehWlAOIbvjYb0nH5dPo+EUs84431qCh+e12j8r+6O wjJg==
X-Gm-Message-State: AMke39myHIPu9Aaouh9nYs0vcViS0X4wLZ7l9vvHSuxiSim/o+BHx9ATmdNWl649ljY/aVwJugTv/BcCBLbyhQ==
X-Received: by 10.223.170.146 with SMTP id h18mr2124326wrc.113.1487889478861; Thu, 23 Feb 2017 14:37:58 -0800 (PST)
MIME-Version: 1.0
Sender: benlaurie@gmail.com
Received: by 10.28.180.7 with HTTP; Thu, 23 Feb 2017 14:37:58 -0800 (PST)
In-Reply-To: <878towah6b.fsf@ta.scs.stanford.edu>
References: <87bmu194rx.fsf@ta.scs.stanford.edu> <CAG5KPzxXu8yuBzg08hjf0aV9hOTgAsAPo_E1P6kLWKTcs76q=g@mail.gmail.com> <878towah6b.fsf@ta.scs.stanford.edu>
From: Ben Laurie <ben@links.org>
Date: Thu, 23 Feb 2017 22:37:58 +0000
X-Google-Sender-Auth: lvMGbBdehazp_Kd1Yn09UPMz9og
Message-ID: <CAG5KPzx20aq3aLAh1snSK9kpUpMt=0QVODV-vd04EDBORU9c8A@mail.gmail.com>
To: David Mazieres expires 2017-05-24 PDT <mazieres-n3exjhjjbqetuet5x9j2ik8c2a@temporary-address.scs.stanford.edu>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ilc/wyhx9a9IeGdFriY5YOX4JH4Nmdw>
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
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: Thu, 23 Feb 2017 22:38:03 -0000

On 23 February 2017 at 18:35, David Mazieres
<dm-list-ietf-ilc@scs.stanford.edu> wrote:
> Ben Laurie <ben@links.org> writes:
>
>>> While obviously consensus mechanisms have been around for decades, one
>>> recent development has been the advent of so-called permissionless
>>> consensus mechanisms with open membership.  These mechanisms allow new
>>> types of system, for instance ones in which mutually distrustful parties
>>> with no pre-existing relationship can execute atomic transactions
>>> together.  If we abstract the Internet slightly (maybe pretending some
>>> centralized IANA-controled identifiers are public keys anyone could have
>>> unilaterally allocated), the Internet, too, starts to look like a
>>> permissionless system.  That's where this idea of "Internet-level"
>>> consensus originates.  Does it make sense to leverage the permissionless
>>> aspects of the Internet to implement some sort of permissionless
>>> consensus mechanism?  Should the IETF be undertaking efforts along these
>>> lines?  Could such efforts benefit existing IETF efforts or solve
>>> existing challenges?  If the answer to any of these questions is yes,
>>> then this mailing list is the place to start throwing out ideas...
>>
>> Sorry to be a bit late to the party here, but I feel this narrow
>> approach is not for the best, for various reasons.
>>
>> a) IMO, it is still not proven that permissionless consensus with open
>> membership is actually possible - as I've argued before, the examples
>> we have now actually rest on an underlying permissioned consensus with
>> somewhat closed membership (e.g. the major mining pools or the code
>> developers), and claims that the permissionless versions are actually
>> not subvertible rely on somewhat weak economic arguments.
>
> Well, there's at least one existence proof, which is the SCP protocol we
> use at Stellar.  SCP changes the question slightly from whether the
> system is subvertible to who is being subverted, because it depends on
> whom people trust.  E.g., if you trust TurkTrust and I trust the
> conjunction of the ACLU and Google, you might get subverted because
> TurkTrust has been known to issue bad certificates.  On the other hand,
> even if Google somehow gets compromised, that won't subvert my view of
> the world so long as the ACLU remains honest.

OK, so here's where I get to confess that I don't understand Stellar,
and, worse, I don't know anyone who does.

Is there an idiot's guide somewhere?

That said, the properties you claim are also trivially obtainable with
a CT-like system, so I totally buy it can be done. But I don't see how
this corresponds to the popular notion of "permissionless"? Not that I
actually care, btw.

>
>> b) CT, for example, needs an internet-wide consensus, in effect, but
>> is not permissionless. At least some variants of the things you
>> mention above that would benefit from consensus are also not
>> permissionless (e.g. auditable Linux distros).
>
> Well, maybe SCP shows that permissionless is not a binary setting.  It's
> important that the ACLU be able to participate in consensus without any
> existing participant's permission, and that people have the option to
> depend on the ACLU for safety should they so desire.  However, unless
> and until people do decide to wait for the ACLU for consensus, the ACLU
> will not have any power.
>
> I think this model is very Internet-like, in that it promotes "tussle
> spaces" that resolve issues by market forces.  Though ultimately I'd
> defer to you on what is and is not workable for CT, it seems to me that
> SCP's model would in fact be good for some future CT 2.0, as well as
> other transparency efforts such as software distribution.  In
> particular, with CT you have a bunch of CAs, and even though not
> everyone agrees on who is and is not a valid CA, there's significant
> transitive overlap.  Moreover, independent third parties should be able
> to audit the system, with end users able to depend on these parties.
> That way, even if some extremely powerful attacker subverts all the
> major players, people can survive by additionally depending on
> independent players (e.g., now to fool me it's not enough to subvert
> Google, you also have to subvert the ACLU).

I totally agree with all of this, but have two comments:

a) it seems utterly disconnected with the standard view of
"permissionless", so I think real care is needed with the charter.

b) whilst I think everyone should choose who they trust, in practice
this is mostly totally unusable. The ability to do it is not a system
problem: you have an answer in Stellar, I have one in CT/Trillian.
Others exist, I am sure. The problem is usability. Who chooses the CAs
you trust, for example? Not you (for most values of "you"), that's for
sure.

>
>> I don't object to those who believe in permissionless trying to work
>> out how to do that, but those of us who don't also need these
>> protocols and I think the IETF should address our needs, too.
>
> Well, two things.  First, thanks for joining the conversation, because
> of course any IETF-based consensus effort should address your needs.  At
> the very least, an IETF-sanctioned "permissionless" consensus protocol
> should probably support a degenerate "permissioned" configuration that
> can serve CT's needs (or those of some future CT 2.0).
>
> Second, the state of the art in decentralized Byzantine agreement may be
> more advanced than a lot of IETF attendees are aware.  Hence, please
> keep an open mind about what is and is not already possible.  Stellar's
> payment network is an existence proof of a production system using this
> technology today.  Since deploying Stellar, several people have people
> approached us with other compelling applications, including package
> management and end-to-end email encryption.

Of course, this is exactly what Trillian
(https://github.com/google/trillian) is all about.

> CT is perhaps a bit different in that it has an unusual requirement to
> "fail open"--e.g., I don't want to stop seeing new web sites just
> because the ACLU's server is down.  That could mean my intuition is not
> right about what is and is not workable for a hypothetical CT 2.0.
> However, there's a good possibility that if, either on this list or in
> Chicago, we hash out a set of requirements for an ideal CT 2.0 consensus
> mechanism, we will find ourselves a lot closer to the ideal than you
> might think.

I dunno, I'm feeling pretty positive right now. :-)