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
- [Ilc] Clarifications and thoughts purpose of ILC … dm-list-ietf-ilc
- Re: [Ilc] Clarifications and thoughts purpose of … Tao Effect
- Re: [Ilc] Clarifications and thoughts purpose of … Tony Arcieri
- Re: [Ilc] Clarifications and thoughts purpose of … David Mazieres
- Re: [Ilc] Clarifications and thoughts purpose of … Ben Laurie
- Re: [Ilc] Clarifications and thoughts purpose of … Tony Arcieri
- Re: [Ilc] Clarifications and thoughts purpose of … David Mazieres
- Re: [Ilc] Clarifications and thoughts purpose of … David Mazieres
- Re: [Ilc] Clarifications and thoughts purpose of … Tony Arcieri
- Re: [Ilc] Clarifications and thoughts purpose of … dm-list-ietf-ilc
- Re: [Ilc] Clarifications and thoughts purpose of … Ben Laurie
- Re: [Ilc] Clarifications and thoughts purpose of … David Mazieres
- Re: [Ilc] Clarifications and thoughts purpose of … Ben Laurie
- Re: [Ilc] Clarifications and thoughts purpose of … David Mazieres
- Re: [Ilc] Clarifications and thoughts purpose of … Ben Laurie