From nobody Fri Feb 10 14:47:56 2017 Return-Path: X-Original-To: ilc@ietf.org Delivered-To: ilc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9F7129B29; Fri, 10 Feb 2017 11:39:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148675558593.29252.3504599276468340795.idtracker@ietfa.amsl.com> Date: Fri, 10 Feb 2017 11:39:45 -0800 Archived-At: X-Mailman-Approved-At: Fri, 10 Feb 2017 14:47:54 -0800 Cc: mshore@fastly.com, ilc@ietf.org, dm-list-ietf-ilc@scs.stanford.edu Subject: [Ilc] New Non-WG Mailing List: Ilc -- Discussion of mechanisms and applications for Internet-level consensus. X-BeenThere: ilc@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "Discussion of mechanisms and applications for Internet-level consensus." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 19:39:46 -0000 A new IETF non-working group email list has been created. List address: ilc@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=ilc To subscribe: https://www.ietf.org/mailman/listinfo/ilc Purpose: Several applications depend on Internet-wide consensus to secure an append-only log, provide tamper-resistant timestamps, and atomically commit transactions across mutually distrustful parties with no preexisting relationship. Examples include: * The IETF trans working group is specifying data structures and operational mechanisms for providing secure logging and auditing of TLS server certificates, but lacks a mechanism for determining consensus among logs (or consensus about whether or not a resource should be logged). These functions are currently served by an experimental gossip protocol that can potentially be strengthened through global consensus. * The Stellar payment network, is used by remittance companies to trade currencies and send payments across the Internet. * UCSD's SPAM (Secure PAckage Manager) project relies on a secure global log both to enable revocation of previously published vulnerable software packages and to guarantee that a particular software release has been publicly available for audit (somewhat like certificate transparency). * Stellar has an ongoing secure naming project that aims to allow domain name owners to assign human-readable names to end-user public keys without retaining the ability to lie about those public keys undetected. This list is to discuss such applications, the mechanisms that can meet their consensus needs, and a potential role of the IETF in devising a stable specification for an Internet-level consensus mechanism. For additional information, please contact the list administrators. From return-hd6ixwbvxdfrj5jkmhwwarrnz6@temporary-address.scs.stanford.edu Fri Feb 10 15:12:42 2017 Return-Path: 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 3831D1295D5; Fri, 10 Feb 2017 15:12:42 -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 44VbmDnoyhRl; Fri, 10 Feb 2017 15:12:40 -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 C830F129401; Fri, 10 Feb 2017 15:12:37 -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 v1ANCbnL007884; Fri, 10 Feb 2017 15:12:37 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1ANCb8i010273; Fri, 10 Feb 2017 15:12:37 -0800 (PST) From: David Mazieres To: trans@ietf.org, saag@ietf.org, ilc@ietf.org Date: Fri, 10 Feb 2017 15:12:37 -0800 Message-ID: <87poip3aje.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Ilc] Internet-level Consensus - new list and possible BoF X-BeenThere: ilc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ilc@ietf.org List-Id: "Discussion of mechanisms and applications for Internet-level consensus." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 23:15:44 -0000 Several applications depend on Internet-wide consensus to secure an append-only log, provide tamper-resistant timestamps, and atomically commit transactions across mutually distrustful parties with no preexisting relationship. Examples include: * The IETF trans working group is specifying data structures and operational mechanisms for providing secure logging and auditing of TLS server certificates, but lacks a mechanism for determining consensus among logs (or consensus about whether or not a resource should be logged). These functions are currently served by an experimental gossip protocol that can potentially be strengthened through global consensus. * The Stellar payment network, is used by remittance companies to trade currencies and send payments across the Internet. * UCSD's SPAM (Secure PAckage Manager) project relies on a secure global log both to enable revocation of previously published vulnerable software packages and to guarantee that a particular software release has been publicly available for audit (somewhat like certificate transparency). * Stellar has an ongoing secure naming project that aims to allow domain name owners to assign human-readable names to end-user public keys without retaining the ability to lie about those public keys undetected. We have just created a new IETF mailing mailing list to discuss such applications, the mechanisms that can meet their consensus needs, and a potential role of the IETF in devising a stable specification for an Internet-level consensus mechanism. The home page for the list is here: https://www.ietf.org/mailman/listinfo/ilc If there is interest in the topic, we would like to organize a BoF in Chicago. Please join the discussion on the list if you might be interested in participating. David From nobody Sun Feb 12 05:19:39 2017 Return-Path: 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 8542112968E for ; Sun, 12 Feb 2017 05:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 pIP7eD2IhPyw for ; Sun, 12 Feb 2017 05:19:36 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 2BD86129618 for ; Sun, 12 Feb 2017 05:19:36 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 888F4280643 for ; Sun, 12 Feb 2017 14:19:34 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 84043280641 for ; Sun, 12 Feb 2017 14:19:34 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 820C3B38003 for ; Sun, 12 Feb 2017 14:19:04 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 62FF840091; Sun, 12 Feb 2017 14:19:04 +0100 (CET) Date: Sun, 12 Feb 2017 14:19:04 +0100 From: Stephane Bortzmeyer To: ilc@ietf.org Message-ID: <20170212131904.54le34z72vyntsof@nic.fr> References: <148675558593.29252.3504599276468340795.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <148675558593.29252.3504599276468340795.idtracker@ietfa.amsl.com> X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Ilc] New Non-WG Mailing List: Ilc -- Discussion of mechanisms and applications for Internet-level consensus. X-BeenThere: ilc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of mechanisms and applications for Internet-level consensus." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 13:19:38 -0000 On Fri, Feb 10, 2017 at 11:39:45AM -0800, IETF Secretariat wrote a message of 21 lines which said: > A new IETF non-working group email list has been created. Congratulations for managing not to spell "blockchain" even once :-) > The Stellar payment network Good, I own 400 lumens :-) > Stellar has an ongoing secure naming project that aims to allow > domain name owners to assign human-readable names to end-user public > keys Is it a reference to ? From nobody Sun Feb 12 17:04:32 2017 Return-Path: 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 AC4091294AA for ; Sun, 12 Feb 2017 17:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 L5THFtJEEAfk for ; Sun, 12 Feb 2017 17:04:28 -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 40FCF1294F0 for ; Sun, 12 Feb 2017 17:04:27 -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 v1D14Ri2082189; Sun, 12 Feb 2017 17:04:27 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1D14QcI023516; Sun, 12 Feb 2017 17:04:26 -0800 (PST) From: David Mazieres To: Stephane Bortzmeyer , ilc@ietf.org In-Reply-To: <20170212131904.54le34z72vyntsof@nic.fr> References: <148675558593.29252.3504599276468340795.idtracker@ietfa.amsl.com> <20170212131904.54le34z72vyntsof@nic.fr> Date: Sun, 12 Feb 2017 17:04:26 -0800 Message-ID: <871sv29a05.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Ilc] New Non-WG Mailing List: Ilc -- Discussion of mechanisms and applications for Internet-level consensus. X-BeenThere: ilc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David Mazieres expires 2017-05-13 PDT List-Id: "Discussion of mechanisms and applications for Internet-level consensus." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 01:04:31 -0000 Stephane Bortzmeyer writes: > On Fri, Feb 10, 2017 at 11:39:45AM -0800, > IETF Secretariat wrote > a message of 21 lines which said: > >> A new IETF non-working group email list has been created. > > Congratulations for managing not to spell "blockchain" even once :-) Thanks. >> The Stellar payment network > > Good, I own 400 lumens :-) Obviously this list isn't about Stellar or Bitcoin. But those systems are an existence proof of consensus technologies not currently in use by any IETF protocols. So to the extent there may be an unmet need, they are worth exploring. >> Stellar has an ongoing secure naming project that aims to allow >> domain name owners to assign human-readable names to end-user public >> keys > > Is it a reference to > ? It's an internal project that could maybe be viewed as v2 of that. But the larger point is that, in the IETF context, such a system would face an unmet need for global consensus. E.g., if I'm an email provider with a domain name, I have no standard way to certify my users' public keys for end-to-end email encryption that gets me out of the trust loop. There are proposals (e.g., CONIKS, the Google/Yahoo end-to-end email encryption system), etc., but they would be strengthened by a global append-only log. David From nobody Mon Feb 13 12:24:30 2017 Return-Path: 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 E5E141298CE for ; Mon, 13 Feb 2017 12:24:28 -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 CisFlHb8GoJK for ; Mon, 13 Feb 2017 12:24:27 -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 D25891298CA for ; Mon, 13 Feb 2017 12:24:27 -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 v1DKOQvv074863 for ; Mon, 13 Feb 2017 12:24:26 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1DKOQRV089581; Mon, 13 Feb 2017 12:24:26 -0800 (PST) From: dm-list-ietf-ilc@scs.stanford.edu To: ilc@ietf.org Date: Mon, 13 Feb 2017 12:24:26 -0800 Message-ID: <87mvdpon45.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Ilc] Welcome to the ILC list X-BeenThere: ilc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David Mazieres expires 2017-05-14 PDT List-Id: "Discussion of mechanisms and applications for Internet-level consensus." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 20:24:29 -0000 Thanks for subscribing to the Internet-level consensus mailing list. Now that we've got 50+ people on the mailing list, let's start the discussion. Consensus is the task of a agreeing on a particular value among multiple valid inputs in a distributed system. This problem is at the heart of fault-tolerant replication and distributed transaction processing. An Internet-level consensus mechanism is one that accommodates the decentralized nature of the Internet to agree on values without relying on a centralized authority for configuration. Specifically, the goal is to achieve consensus in settings where there may be Internet-wide benefit from agreement, yet the security concerns of participants and the multi-national nature of the network preclude any globally-acceptable consortium in which to concentrate trust. We created this mailing list on the hypothesis that there's an unmet need for this kind of Internet-level consensus. So if you have applications for such a technology, please speak up. Other good questions to discuss: What kind of properties do you think Internet-level consensus should have? What is the best form for an IETF contribution in the area (i.e., a single global service, vs. a protocol with many instances)? Are there enhancements/improvements to other Internet technologies that would make it easier or more efficient to achieve consensus? And finally, of course, what other questions would you like to see discussed on the list? David From nobody Wed Feb 15 22:30:07 2017 Return-Path: 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 795EB1295E5 for ; Wed, 15 Feb 2017 22:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=taoeffect.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 atUBwWv-dVAY for ; Wed, 15 Feb 2017 22:30:04 -0800 (PST) Received: from homiemail-a9.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6B61295C0 for ; Wed, 15 Feb 2017 22:30:04 -0800 (PST) Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id 948C85BE070 for ; Wed, 15 Feb 2017 22:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h=from :content-type:mime-version:subject:message-id:date:to; s= taoeffect.com; bh=/LgqRG00xC9e62xqm0XDY8CMAps=; b=YL3X0kIFcZaoDe dtNBbNTKOFe8+klhEgZd17NdwW51AC6yP3R+DuAwThAW/9B/CF/tkZdjWA5Uy7e3 2JpacmXO7y9uA6lcsXDfjJeTOYZoQ8RDoNj7lGu0BL3TkGJlxKIZK4O34NQLO36M nhWG2ZJKG1pc4qIUog3TsaFHTuEyE= Received: from [192.168.42.64] (184-23-255-25.fiber.dynamic.sonic.net [184.23.255.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 791E95BE06B for ; Wed, 15 Feb 2017 22:30:03 -0800 (PST) From: Tao Effect Content-Type: multipart/signed; boundary="Apple-Mail=_2F7B5707-B30F-4386-81FE-8F195A2AA0D9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Mao-Original-Outgoing-Id: 508919402.394213-2a74eefb39063d66b2bd5881f44b6dc3 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <77FF4B0A-F090-412C-B007-5F6D48EC9E9A@taoeffect.com> Date: Wed, 15 Feb 2017 22:30:02 -0800 To: ilc@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Ilc] Genuine concern: is the the purpose of this group to create an Internet-cartel? X-BeenThere: ilc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of mechanisms and applications for Internet-level consensus." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 06:30:05 -0000 --Apple-Mail=_2F7B5707-B30F-4386-81FE-8F195A2AA0D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi list, Judging by the name of this group I will not be surprised if this email = is simply ignored, but I'm obligated by conscience to voice my concern, = if only so that future historians can search these archives and see that = yes, someone did contact this group and ask them if they were aware of = the consequences, i.e. the high likelihood of turning the Internet back = into 20th century cable news. It is not clear to me, from the name of this working group, whether it = understands the meaning of "consensus". My OS X dictionary says: > general agreement: a consensus of opinion among judges That "among judges" part is of central importance. Without it, = "consensus" would mean something completely different. To emphasize: consensus *always* occurs within the context of a _group_. The Internet is comprised of billions of individuals and billions of = machines. So "Internet-level consensus" suggests consensus among a group = of said billion individuals. That is clearly impossible, I think all = here would agree. Therefore, what this working group is really proposing is not = "Internet-level consensus", but consensus between a cartel of companies = whose consensus they expect the rest of the Internet to follow and = respect. In other words, a cartel that imposes its decisions upon the = entire world. Please note: I am fully aware of the transparency and gossip efforts = conducted by [trans], have written reviews of them [1], and compared = Certificate Transparency to other transparency efforts like CONIKS [2] = -- so you do not need to assume that I'm unaware of the impact of those = technologies. As mentioned in those links, especially [2], centralized = consensus systems are fundamentally incapable of censorship-resistance. So, if cartel-consensus imposed on the Internet is what this group has = in mind, please be aware that such a course of action will almost = certainly lead to the destruction of the Internet as we know it. I hope = that's not the purpose of the working group. It *is* possible to have an "Internet-level consensus thing", but the = only such thing I know exists would be the creation of a totally = _consensus-agnostic_ protocol that lets end users choose for themselves = which consensus group they are trusting (e.g. via a TLD extension, for = example). One such protocol, DPKI [3], has been sketched out by a = different group, Rebooting The Web of Trust, headed by Christopher = Allen, co-author of SSL/TLS. So my question is: which of these visions does the group have in mind? (A) The creation of a *specific* consensus protocol, which will lead to = the centralization of the Internet in the hands of a cartel and = therefore its destruction? or (B) The creation of a completely agnostic consensus protocol that works = with all consensus systems, be it Stellar, Ripple, Bitcoin, etc.? Thanks, and again, I mean no disrespect, only to share a genuine = concern, and curiosity as to whether this group plans on doing (A) or = (B) above. [1] https://blog.okturtles.com/tag/certificate-transparency/ [2] = https://blog.okturtles.com/2017/02/coniks-vs-key-transparency-vs-certifica= te-transparency-vs-blockchains/ [3] = https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/f= inal-documents/dpki.pdf - Greg -- Please do not email me anything that you are not comfortable also = sharing with the NSA. --Apple-Mail=_2F7B5707-B30F-4386-81FE-8F195A2AA0D9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYpUbqAAoJEOxnICvpCVJHzUAQAKnWjjXMWYtcbzcLgstS1WNY TtOlB7oNf20hCmNVlvZ8e0s2MiNGnsAYe3IkARJRO8w1uHhJSDh2eDV1Lp7y8EQn tS7mBFfq+QXzg6b0bZf1KjfiaUeuyURtKVEo+mqbOJ/rjWcStVfLoNyuZQLff1L1 Vrvo01wZoZ2am0LgOUufeJRu2FMXcpRGS7BO3sWA0HmV1WftkE2AStuPVxgQMRoK LzmTEH4iNUAO2iOL5zy3bCNKpeb4RzdhY82hA1BPSuDZFq/q6m+Wdrh6NuySeZts 6/Urs+BaBuI5kOAtevtrJOD3RgkKAM6CTGbn/NVNfwDMigpFKk8Q/nY+QUBb4V20 hSwmfY9iD3vBWsPfG0SpVg5Pb3QGukEP2Bj6oiEGhCkPjwrh0JtKs6ANkyHgIQQu vmUkO2ggu33QxoQUL4+ksOJsCOrTYXFwBqyL/X9aPWzP8lDzrOJN1txMBNx7ak3s U0YxwXpEgw9or6zvrnTjg+JY4jJCBarp33+W5ZfnGSZo4cJiX/BS/tOvPA1q27eK r4W63jIDktu5HBxQNS6H7qYU9f3x4tkjBwWA4KgeOhRA7JN3GRMmtK2e7I34eN/T sIDpZAnTdnG/6SxN7df/EIdw/yI6yrEYFp2OiwbejWTElrL0r32+xqEj71hE8cXD 0IT0YTzrmXyGNcgLD6J6 =JARE -----END PGP SIGNATURE----- --Apple-Mail=_2F7B5707-B30F-4386-81FE-8F195A2AA0D9-- From nobody Thu Feb 16 10:23:43 2017 Return-Path: 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 6B7DD12969B for ; Thu, 16 Feb 2017 10:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 AHfXteV38zZn for ; Thu, 16 Feb 2017 10:23:36 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 CD50B129691 for ; Thu, 16 Feb 2017 10:23:18 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id u25so23499550qki.2 for ; Thu, 16 Feb 2017 10:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mf7uFXfEov5fbc3e3r2dvPlH2fWpiK41meDv3UPjLb4=; b=YooRS65BEBqoE+4lIBRNyLRdEzPtihc2c56FIL60Wf4z3NtCPIooJF9dndFR7WVEEk 6sZi42rY56yRTeQx+xgtCumaJSLpr7goUZNM3eH0dxhKCDCdQ8bKOhu4rh+fwiBSs7fG oHCCYEx7w8gYdyGLBeKubtz4rz0vWc6i86V1I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Mf7uFXfEov5fbc3e3r2dvPlH2fWpiK41meDv3UPjLb4=; b=CgXy/0q3xLtIz0apxpqtpzy7+AQBmNW9exD8tUiNRqvGjfAPDI7E8lBin31AhwUe7A vnb3JhBYHMlFs990Rkdq57/q6PaKdPyhhz53t0s9ijk4T6Hhzmrg6LGsoK46YGFbkvq7 XzAayLze7NzzjeGhOTWbROrj3Sf0FiDRFF34qtO0j5mDRB/ON5q4n/16p9sFLt7qhW/k aWvLH095oEsFd5i65MWBSemETd25Yf2w6IcL5t5BMpZcXZsvC3nAhtfR/W/bjxBk0loO VDGNJOqt8C5L8385Anxo+MQyx4J933YCGZ/lyGLThSGTr4RI2qrhaCLExXV0z00VdWZr meRw== X-Gm-Message-State: AMke39l4oopkt06TPkC4lxV6lif82Rj/ToEE7LVc5WttLojJXHJwgz7pk7lsZGC3txncwhqeFw/77wMSVnvk0A== X-Received: by 10.55.212.23 with SMTP id l23mr3264761qki.247.1487269397587; Thu, 16 Feb 2017 10:23:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Thu, 16 Feb 2017 10:23:17 -0800 (PST) X-Originating-IP: [72.246.0.14] In-Reply-To: <87mvdpon45.fsf@ta.scs.stanford.edu> References: <87mvdpon45.fsf@ta.scs.stanford.edu> From: Kyle Rose Date: Thu, 16 Feb 2017 13:23:17 -0500 Message-ID: To: David Mazieres expires 2017-05-14 PDT Content-Type: multipart/alternative; boundary=001a1149cdc6212e820548a9e47d Archived-At: Cc: ilc@ietf.org Subject: Re: [Ilc] Welcome to the 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:23:39 -0000 --001a1149cdc6212e820548a9e47d Content-Type: text/plain; charset=UTF-8 What problem class were you thinking of? If (relative to the other thread from this morning) we wanted internet-level consensus on a voluntary basis, such that different entities could join different consortia for determining consensus, what classes of problems require this consensus to be real-time and automated as opposed to scheduled ("On this date...") or determined top-down (admin configures things directly)? One of the examples I've brought up with Mirja, Brian, and Stephen in discussions on PLUS was around dynamically disabling the acceptance of hijacked or squatted code points, option numbers, etc., if they've been hijacked for nefarious purposes. One of the critical privacy issues with extensible protocols is that they provide hooks that can be hijacked by nation-states and others for purposes of user tracking with the property that this information survives end-to-end over the general internet. Without these hooks, nation-states are forced to add or remove this information at the borders of their own networks, an operation that is infrastructure-heavy, and is at least likely to run into compatibility problems with commodity hardware, raising costs for their own users. The downside for internet users is that without these hooks the protocols are less able to evolve without wholesale replacement. It also turns out to be really hard to define a protocol with no available space for squatters. A single bit can be misused, and designing a protocol without any subliminal channels is very difficult, and again would probably result in protocols that can't be extended to meet the needs of new applications or of constantly-evolving network technologies. What if we could produce extensible protocols but provide a mechanism for disabling arbitrary subsets of that protocol based on abuse by network actors? E.g., if some nation-state starts squatting on a TCP option, inserting user identifying information into the payload, what if the internet community at large had the ability to reconfigure all (or a critical mass of) devices to drop all packets with that option? In some sense this is kind of a big red button for the internet: it's a mechanism that might never need to be used because the mere threat of a network partition could be sufficient to prevent this kind of thing. The problem with something like a machine-readable registry at a predefined URL is that it can be hijacked by said nation-states and reconfigured to suit their whims. But (at least my Rorschach test-conception of) ILC would be a lot harder to hijack. The consensus could even just be for the URL of the object describing the protocol restrictions. I imagine something like this could also be used for evil, but nothing is currently stopping network operators from doing bad things on their own, and of course individual device configuration would still be subject to the desires of the owner and of governments with jurisdiction, just as today. Kyle On Mon, Feb 13, 2017 at 3:24 PM, wrote: > Thanks for subscribing to the Internet-level consensus mailing list. > Now that we've got 50+ people on the mailing list, let's start the > discussion. > > Consensus is the task of a agreeing on a particular value among > multiple valid inputs in a distributed system. This problem is at the > heart of fault-tolerant replication and distributed transaction > processing. > > An Internet-level consensus mechanism is one that accommodates the > decentralized nature of the Internet to agree on values without > relying on a centralized authority for configuration. Specifically, > the goal is to achieve consensus in settings where there may be > Internet-wide benefit from agreement, yet the security concerns of > participants and the multi-national nature of the network preclude any > globally-acceptable consortium in which to concentrate trust. > > We created this mailing list on the hypothesis that there's an unmet > need for this kind of Internet-level consensus. So if you have > applications for such a technology, please speak up. > > Other good questions to discuss: What kind of properties do you think > Internet-level consensus should have? What is the best form for an IETF > contribution in the area (i.e., a single global service, vs. a protocol > with many instances)? Are there enhancements/improvements to other > Internet technologies that would make it easier or more efficient to > achieve consensus? And finally, of course, what other questions would > you like to see discussed on the list? > > David > > _______________________________________________ > Ilc mailing list > Ilc@ietf.org > https://www.ietf.org/mailman/listinfo/ilc > --001a1149cdc6212e820548a9e47d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What problem class were you = thinking of? If (relative to the other thread from this morning) we wanted = internet-level consensus on a voluntary basis, such that different entities= could join different consortia for determining consensus, what classes of = problems require this consensus to be real-time and automated as opposed to= scheduled ("On this date...") or determined top-down (admin conf= igures things directly)?

One of the examples I've brought = up with Mirja, Brian, and Stephen in discussions on PLUS was around dynamic= ally disabling the acceptance of hijacked or squatted code points, option n= umbers, etc., if they've been hijacked for nefarious purposes. One of t= he critical privacy issues with extensible protocols is that they provide h= ooks that can be hijacked by nation-states and others for purposes of user = tracking with the property that this information survives end-to-end over t= he general internet. Without these hooks, nation-states are forced to add o= r remove this information at the borders of their own networks, an operatio= n that is infrastructure-heavy, and is at least likely to run into compatib= ility problems with commodity hardware, raising costs for their own users. = The downside for internet users is that without these hooks the protocols a= re less able to evolve without wholesale replacement.

It also = turns out to be really hard to define a protocol with no available space fo= r squatters. A single bit can be misused, and designing a protocol without = any subliminal channels is very difficult, and again would probably result = in protocols that can't be extended to meet the needs of new applicatio= ns or of constantly-evolving network technologies.

What if we = could produce extensible protocols but provide a mechanism for disabling ar= bitrary subsets of that protocol based on abuse by network actors? E.g., if= some nation-state starts squatting on a TCP option, inserting user identif= ying information into the payload, what if the internet community at large = had the ability to reconfigure all (or a critical mass of) devices to drop = all packets with that option? In some sense this is kind of a big red butto= n for the internet: it's a mechanism that might never need to be used b= ecause the mere threat of a network partition could be sufficient to preven= t this kind of thing.

The problem with something like a machin= e-readable registry at a predefined URL is that it can be hijacked by said = nation-states and reconfigured to suit their whims. But (at least my Rorsch= ach test-conception of) ILC would be a lot harder to hijack. The consensus = could even just be for the URL of the object describing the protocol restri= ctions.

I imagine something like this could also be used for e= vil, but nothing is currently stopping network operators from doing bad thi= ngs on their own, and of course individual device configuration would still= be subject to the desires of the owner and of governments with jurisdictio= n, just as today.

Kyle

=

On Mon, Feb 13, 2017 at 3:24 PM, <dm-list-ietf-ilc@scs.s= tanford.edu> wrote:
Thanks = for subscribing to the Internet-level consensus mailing list.
Now that we've got 50+ people on the mailing list, let's start the<= br> discussion.

Consensus is the task of a agreeing on a particular value among
multiple valid inputs in a distributed system.=C2=A0 This problem is at the=
heart of fault-tolerant replication and distributed transaction
processing.

An Internet-level consensus mechanism is one that accommodates the
decentralized nature of the Internet to agree on values without
relying on a centralized authority for configuration.=C2=A0 Specifically, the goal is to achieve consensus in settings where there may be
Internet-wide benefit from agreement, yet the security concerns of
participants and the multi-national nature of the network preclude any
globally-acceptable consortium in which to concentrate trust.

We created this mailing list on the hypothesis that there's an unmet need for this kind of Internet-level consensus.=C2=A0 So if you have
applications for such a technology, please speak up.

Other good questions to discuss:=C2=A0 What kind of properties do you think=
Internet-level consensus should have?=C2=A0 What is the best form for an IE= TF
contribution in the area (i.e., a single global service, vs. a protocol
with many instances)?=C2=A0 Are there enhancements/improvements to other Internet technologies that would make it easier or more efficient to
achieve consensus?=C2=A0 And finally, of course, what other questions would=
you like to see discussed on the list?

David

_______________________________________________
Ilc mailing list
Ilc@ietf.org
https://www.ietf.org/mailman/listinfo/ilc

--001a1149cdc6212e820548a9e47d-- From nobody Thu Feb 16 10:44:36 2017 Return-Path: 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 6036F12953E for ; Thu, 16 Feb 2017 10:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg 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 SBOL48taGqOI for ; Thu, 16 Feb 2017 10:44:34 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 F2A5F129624 for ; Thu, 16 Feb 2017 10:44:33 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id p22so24292090qka.0 for ; Thu, 16 Feb 2017 10:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z3HlvY1wPQz/1j79mps7isvwr+/dI1T7N68kv/P6CD8=; b=l5kIjVkZJoYQuJWs/qrVoAmi6o1MlE8TVygM7/KCngDswFV4MS3Pnb4Xj58r2Xvuh1 f5Qj9lzAnPu4v0vhnyLjIMVK+V5VTlhK9EWTgJTWDDNhlHeHV0kOGgcUUVLw7A5+iaNa y4dstxj7ZedAHq9P8FiZE8B9fe9cPgmDVA9Hs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z3HlvY1wPQz/1j79mps7isvwr+/dI1T7N68kv/P6CD8=; b=nzAt2y2bRC+4lmFDW1By8Gosq0LE/pzKCoePFWmBz+0nF5oMdDilv+1y8y8H+u0bn9 p21iLGnYtlt1o8qeQAvubEKYGePmm+8lvz2U8g2+JfDVfS8O7rNZuAkG6sijXwh8UrhP tV8KZ8IdAA6lxGo09s5j1sRamJmrhACtkV7IGdwVBJrh9sG8Ta4yWYkVUtkI5wLem4k4 IB6vqOgtwnlLxRYL5AWbwHoswgWGlDiL3Z49cMmKgYGB+bIwFnQah/Dxy8MP9syILQR2 hgjoFN9XxA0CCOCSfiGwn23/aptnugRMWR8gVEzylTCpAra2RU9T2qm8ExaIZ1fi61gf buZw== X-Gm-Message-State: AMke39klH/ltliPg3g6wi8fj9hF6MEW6VaIoXLY8wPGe96k7Ua8PClLk0g7cOtPkvZnJfaCA4+LSSYUtHiPm7R3+ X-Received: by 10.55.113.129 with SMTP id m123mr3870517qkc.47.1487270673040; Thu, 16 Feb 2017 10:44:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.94.244 with HTTP; Thu, 16 Feb 2017 10:44:12 -0800 (PST) In-Reply-To: <87mvdpon45.fsf@ta.scs.stanford.edu> References: <87mvdpon45.fsf@ta.scs.stanford.edu> From: Tom Ritter Date: Thu, 16 Feb 2017 12:44:12 -0600 Message-ID: To: David Mazieres expires 2017-05-14 PDT Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: ilc@ietf.org Subject: Re: [Ilc] Welcome to the 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:44:35 -0000 On 13 February 2017 at 14:24, wrote: > Thanks for subscribing to the Internet-level consensus mailing list. > Now that we've got 50+ people on the mailing list, let's start the > discussion. > > Consensus is the task of a agreeing on a particular value among > multiple valid inputs in a distributed system. This problem is at the > heart of fault-tolerant replication and distributed transaction > processing. > > An Internet-level consensus mechanism is one that accommodates the > decentralized nature of the Internet to agree on values without > relying on a centralized authority for configuration. Specifically, > the goal is to achieve consensus in settings where there may be > Internet-wide benefit from agreement, yet the security concerns of > participants and the multi-national nature of the network preclude any > globally-acceptable consortium in which to concentrate trust. I'm a little confused here. The very first example listed on the mailing list description is: """ The IETF trans working group is specifying data structures and operational mechanisms for providing secure logging and auditing of TLS server certificates, but lacks a mechanism for determining consensus among logs (or consensus about whether or not a resource should be logged). These functions are currently served by an experimental gossip protocol that can potentially be strengthened through global consensus. """ The Gossip protocol (of which I am an author) does not really attempt to determine consensus; nor does it attempt to "[agree] on a particular value among multiple valid inputs in a distributed system". It attempts to expose all valid values (meaning has-a-signatures-that-validates) to an Internet-wide group of participants. If there's a piece of data, signed by a log, we want to show share the data (or a derivative of it) with "The Internet" (for some definition of "The Internet") can "The Internet" can review it. I suppose, after gossip occurs, there is a consensus mechanism. But it's really very simple and mathematically sound. "Given all the inputs I have, can I assemble them into a single consistent Append-Only Merkle Tree; or not?" There is no participation required with anyone else, the 'consensus mechanism' is positively true or false for everyone independently. It's the data gathering that's tough. -tom From nobody Thu Feb 16 12:14:36 2017 Return-Path: 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 AE2BC129689 for ; Thu, 16 Feb 2017 12:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=taoeffect.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 iD7N_B2ErHaR for ; Thu, 16 Feb 2017 12:14:31 -0800 (PST) Received: from homiemail-a9.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2DB129603 for ; Thu, 16 Feb 2017 12:14:31 -0800 (PST) Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id 1EC795BE06B; Thu, 16 Feb 2017 12:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=On4fAiOMHZE5wzUWo o5gExmYoIg=; b=PyZOMhX6jwbKc/Ld61Ph60UhyPaqb80imE0PuzQpgNddj3WNf rttkTNMfoFq4wScaXb9xqB3wLeLBiq5t3mHjyFn5ylPSr7PJ/B5kOhp5o5OP7eGA sYAj0Icdj4PnOtigTwHTSQKtdUCN8GbfyGDI1uWxcPCGOOZxUU1hw3NIVA= Received: from [192.168.42.64] (184-23-255-25.fiber.dynamic.sonic.net [184.23.255.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPSA id DB92D5BE06D; Thu, 16 Feb 2017 12:14:30 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_D30708D0-1998-4373-BED5-A41EA8D4AAC1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Tao Effect In-Reply-To: Date: Thu, 16 Feb 2017 12:14:29 -0800 X-Mao-Original-Outgoing-Id: 508968869.554236-89e49b9357991dd65ad10841a9c39d0b Message-Id: <78FD9CB0-0DEC-4221-8D41-6A25E9027459@taoeffect.com> References: <87mvdpon45.fsf@ta.scs.stanford.edu> To: Tom Ritter X-Mailer: Apple Mail (2.3259) Archived-At: Cc: ilc@ietf.org, David Mazieres expires 2017-05-14 PDT Subject: Re: [Ilc] Welcome to the 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:14:35 -0000 --Apple-Mail=_D30708D0-1998-4373-BED5-A41EA8D4AAC1 Content-Type: multipart/alternative; boundary="Apple-Mail=_86A21E44-8271-417E-8D08-130A8954FCBE" --Apple-Mail=_86A21E44-8271-417E-8D08-130A8954FCBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 What this group is doing, which is not very clear from its = self-description, is the creation of a consensus-based namespace. The Internet does not currently have consensus-based namespaces. DNS, for example, does not operate on any real form of consensus. For this reason, it is also not secure. Anyone who can MITM a network = connection, can override apple.com to be anything = they want, along with any other name in the insecure, federated ICANN = namespace. A *consensus-based namespace*, on the other hand=E2=80=94as this group = and [trans] are proposing=E2=80=94consolidates ownership and definition = of the entire namespace to a group that attempts to maintain consensus. The means by which consensus is achieved *matters a great deal*, but = some general statements are possible too. In the example of Stellar, consensus is restricted to a small cartel, = and the protocol's inability to resolve consensus forks means that this = cartel will most likely only get smaller over time, since participation = requires the _permission_ of the existing cartel. FYI, Stellar's = marketing in this department is also highly misleading [1]. What you're left with is a log, and it can be "append-only", but that = really doesn't matter much if the proposal is for the /entire Internet/ = to use *just* that one log. That is tantamount to a global, Internet = takeover by a cartel. It's important to emphasize: _such a group would have *total power* to = decide who is and who is not allowed to have a website._ A consensus-based namespace offers security=E2=80=94but only if it's not = a defacto namespace, but one of an arbitrary number of consensus-based = namespaces. - Greg [1] https://twitter.com/taoeffect/status/832284907342688256 = -- Please do not email me anything that you are not comfortable also = sharing with the NSA. > On Feb 16, 2017, at 10:44 AM, Tom Ritter > wrote: >=20 > The Gossip protocol (of which I am an author) does not really attempt > to determine consensus; nor does it attempt to "[agree] on a > particular value among multiple valid inputs in a distributed system". >=20 > It attempts to expose all valid values (meaning > has-a-signatures-that-validates) to an Internet-wide group of > participants. If there's a piece of data, signed by a log, we want to > show share the data (or a derivative of it) with "The Internet" (for > some definition of "The Internet") can "The Internet" can review it. >=20 > I suppose, after gossip occurs, there is a consensus mechanism. But > it's really very simple and mathematically sound. "Given all the > inputs I have, can I assemble them into a single consistent > Append-Only Merkle Tree; or not?" There is no participation required > with anyone else, the 'consensus mechanism' is positively true or > false for everyone independently. It's the data gathering that's > tough. >=20 > -tom >=20 > _______________________________________________ > Ilc mailing list > Ilc@ietf.org > https://www.ietf.org/mailman/listinfo/ilc --Apple-Mail=_86A21E44-8271-417E-8D08-130A8954FCBE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 What this group is doing, which is not very clear from its = self-description, is the creation of a consensus-based namespace.

The Internet does not = currently have consensus-based namespaces.

DNS, for example, does not operate on = any real form of consensus.

For this reason, it is also not secure. Anyone who can MITM = a network connection, can override apple.com to be anything they want, along with any = other name in the insecure, federated ICANN namespace.

A *consensus-based = namespace*, on the other hand=E2=80=94as this group and [trans] are = proposing=E2=80=94consolidates ownership and definition of the entire = namespace to a group that attempts to maintain consensus.

The means by which = consensus is achieved *matters a great deal*, but some general = statements are possible too.

In the example of Stellar, consensus is = restricted to a small cartel, and the protocol's inability to resolve = consensus forks means that this cartel will most likely only get smaller = over time, since participation requires the _permission_ of the existing = cartel. FYI, Stellar's marketing in this department is also highly = misleading [1].

What you're left with is a log, and it can be "append-only", = but that really doesn't matter much if the proposal is for the /entire = Internet/ to use *just* that one log. That is tantamount to a global, = Internet takeover by a cartel.

It's important to = emphasize: _such a group would have *total power* to decide who is and = who is not allowed to have a website._

A consensus-based namespace offers = security=E2=80=94but only if it's not a defacto namespace, but one of an = arbitrary number of consensus-based namespaces.

- Greg

[1] https://twitter.com/taoeffect/status/832284907342688256

--
Please do not email me anything that you are not = comfortable also sharing with the NSA.

On Feb 16, 2017, at 10:44 AM, Tom Ritter <tom@ritter.vg> = wrote:

The Gossip = protocol (of which I am an author) does not really attempt
to determine consensus; nor does it attempt to "[agree] on = a
particular value among multiple valid inputs in a = distributed system".

It attempts to expose = all valid values (meaning
has-a-signatures-that-validates) = to an Internet-wide group of
participants. If there's a = piece of data, signed by a log, we want to
show share the = data (or a derivative of it) with "The Internet" (for
some = definition of "The Internet") can "The Internet" can review it.

I suppose, after gossip occurs, there is a = consensus mechanism. But
it's really very simple and = mathematically sound. "Given all the
inputs I have, can I = assemble them into a single consistent
Append-Only Merkle = Tree; or not?" There is no participation required
with = anyone else, the 'consensus mechanism' is positively true or
false for everyone independently. It's the data gathering = that's
tough.

-tom

_______________________________________________
Ilc mailing list
Ilc@ietf.org
https://www.ietf.org/mailman/listinfo/ilc

= --Apple-Mail=_86A21E44-8271-417E-8D08-130A8954FCBE-- --Apple-Mail=_D30708D0-1998-4373-BED5-A41EA8D4AAC1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYpgglAAoJEOxnICvpCVJH7bgQALTmpc7U7lgKutXzz1PN7WlV 8gEDHJLMEZ/AP30lnn594brQzgEXXpEHo+vSxjOrGM//bvorkaRs4YrtYISaOo2l Y0As/M9C8L/QexBzcS5gjmEPln5JJdFpZ8j5qvo3F6OJ4hseOY5ggyqRyledC13s 0KkalSxu8sssN+yxvdkHA/ghBWyTkK/E4D3DVtH186Sb88H6YS2iBf34Lf0WcUH/ o6uJ6KxZKErBymZIJb5oZicN1jH7yyqe6g/qyp1x0h2fMoHhtXhlIYCQBd6f+4lD EWQSzDMtkeas0Ov/wI7DZaHLzrb4F62Vxz81b5LtfPqTuKkixAzQG1sCelhajRgt 1YNFmIIGY6GFi+96JwJMX7zKVTaWjuEVI3D73gbGaCtXl8HdeqrHjLZ4RrCg+69s atfvSMHWCHF/Ktjw9I1NjJHZUbpasAYhN+JoBPu7OEp1r1/lH6hjZvvZ1TwSVzKV Fle5BJ0QKbn5fm3M8zTcGjrlz1Cr5RlY6suAvaND7wf4U1zzkl4okWe8yn/bO+o5 yidW/Ko4cRRyZFgU6MxgJAZ6rfI5w0V3IH1UaeUiWwvcc4l2SpJ8Ng46Y9VEuL6t aTQO+dNXfZQzwmRsLbndyOj3OsjQbXx07RaXgqMSSmw5LEqzz2ZVb4OmKVyuoZ64 egUA4Vig+P1quR+w2If3 =hDj+ -----END PGP SIGNATURE----- --Apple-Mail=_D30708D0-1998-4373-BED5-A41EA8D4AAC1-- From nobody Thu Feb 16 13:58:46 2017 Return-Path: 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 970781296FA for ; Thu, 16 Feb 2017 13:58:45 -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 Pl9uVIbOTZUl for ; Thu, 16 Feb 2017 13:58:44 -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 95CB31296F9 for ; Thu, 16 Feb 2017 13:58:44 -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 v1GLwhtn019484 for ; Thu, 16 Feb 2017 13:58:43 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1GLwh7S054797; Thu, 16 Feb 2017 13:58:43 -0800 (PST) From: dm-list-ietf-ilc@scs.stanford.edu To: ilc@ietf.org Date: Thu, 16 Feb 2017 13:58:42 -0800 Message-ID: <87bmu194rx.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [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-17 PDT List-Id: "Discussion of mechanisms and applications for Internet-level consensus." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 21:58:45 -0000 The fact that the term consensus has a colloquial meaning may be generating confusion among some members of the list. As intended in the list name, the term consensus refers to a narrow distributed systems definition, namely the problem for a group of nodes to pick an input value such that there is both agreement (all nodes output the same value) and validity (the output equals one of the valid inputs, ruling out vacuous solutions like always outputting zero). This is not to be confused with other meanings of the word, as in "rough consensus and running code," or consensus in any kind of a governance context. Many kinds of distributed system leverage some a consensus mechanism. At a high level, one of the things we might want to discuss in this list is whether it could be beneficial for the IETF to standardize some kind of consensus protocol or service. Such an effort could provide a useful building block for new or enhanced applications such as Internet payments, auditable software packages, end-to-end email encryption, and probably more things I haven't thought of yet. The goal of this list is certainly not to replace existing protocols or to change Internet governance. 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... David From nobody Thu Feb 16 14:14:06 2017 Return-Path: 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 76E93129577 for ; Thu, 16 Feb 2017 14:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=taoeffect.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 RWib8441jkK4 for ; Thu, 16 Feb 2017 14:14:02 -0800 (PST) Received: from homiemail-a9.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523E5129556 for ; Thu, 16 Feb 2017 14:14:02 -0800 (PST) Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id CE26D5BE06D; Thu, 16 Feb 2017 14:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=4e6j0/7rMffnD5GOi tR/dt/+ggs=; b=Lh3xbATOWL5Yc3IQudKz4ah7WA4I13hnKVrICNJSdzN1bfS8e 1BHNzozf/l7vFm53NUGvxMrSPX4fos8T4bC2belo4S/nW+6d4GeV5aMmlp73I9Zy cMwbPSpKYUuBiyW/iutZRQ/WytfO1rqatY37is/aesBDtrCVUWFhn4c5Ak= Received: from [192.168.42.64] (184-23-255-25.fiber.dynamic.sonic.net [184.23.255.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 9A1EA5BE06B; Thu, 16 Feb 2017 14:14:01 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_62B2D672-13B0-4852-8282-5CD13ADF4BB3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Tao Effect In-Reply-To: <87bmu194rx.fsf@ta.scs.stanford.edu> Date: Thu, 16 Feb 2017 14:14:00 -0800 X-Mao-Original-Outgoing-Id: 508976040.494503-8f8ef18995d7b6e28d621f4367072c91 Message-Id: <70C26D16-9C7E-4EC9-9BC6-6BF330AAA596@taoeffect.com> References: <87bmu194rx.fsf@ta.scs.stanford.edu> To: David Mazieres expires 2017-05-17 PDT X-Mailer: Apple Mail (2.3259) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 22:14:04 -0000 --Apple-Mail=_62B2D672-13B0-4852-8282-5CD13ADF4BB3 Content-Type: multipart/alternative; boundary="Apple-Mail=_932B6897-2D14-4158-97F9-1CF8195D48DF" --Apple-Mail=_932B6897-2D14-4158-97F9-1CF8195D48DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > The fact that the term consensus has a colloquial meaning may be > generating confusion among some members of the list. Which members? Bang them! >:-D > As intended in the > list name, the term consensus refers to a narrow distributed systems > definition, namely the problem for a group of nodes to pick an input > value such that there is both agreement (all nodes output the same > value) and validity (the output equals one of the valid inputs, ruling > out vacuous solutions like always outputting zero). This is not to be > confused with other meanings of the word, as in "rough consensus and > running code," or consensus in any kind of a governance context. I'm told they're fully aware of that. > Many kinds of distributed system leverage some a consensus mechanism. > At a high level, one of the things we might want to discuss in this = list > is whether it could be beneficial for the IETF to standardize some = kind > of consensus protocol or service. As stated before on this list [1, 2], and as stated elsewhere on the web = in semi-mathematical form [3,4], if such a consensus protocol or service = is used with Certificate Transparency or anything else related to DNS, = that would be to kill the Internet. But you're welcome to work on a consensus-agnostic protocol if your = intentions are benevolent. - Greg [1] = https://mailarchive.ietf.org/arch/msg/ilc/BmFgooRm5GikT6mwhx9yOZgL1G8 = [2] = https://mailarchive.ietf.org/arch/msg/ilc/tUirMiYqzIogI1S14qRKhY8Fz0E = [3] https://blog.bigchaindb.com/the-dcs-triangle-5ce0e9e0f1dc#.24dexymvl = [4] = https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob= /master/topics-and-advance-readings/Slepaks-Triangle.pdf = -- Please do not email me anything that you are not comfortable also = sharing with the NSA. > On Feb 16, 2017, at 1:58 PM, dm-list-ietf-ilc@scs.stanford.edu = wrote: >=20 > The fact that the term consensus has a colloquial meaning may be > generating confusion among some members of the list. As intended in = the > list name, the term consensus refers to a narrow distributed systems > definition, namely the problem for a group of nodes to pick an input > value such that there is both agreement (all nodes output the same > value) and validity (the output equals one of the valid inputs, ruling > out vacuous solutions like always outputting zero). This is not to be > confused with other meanings of the word, as in "rough consensus and > running code," or consensus in any kind of a governance context. >=20 > Many kinds of distributed system leverage some a consensus mechanism. > At a high level, one of the things we might want to discuss in this = list > is whether it could be beneficial for the IETF to standardize some = kind > of consensus protocol or service. Such an effort could provide a = useful > building block for new or enhanced applications such as Internet > payments, auditable software packages, end-to-end email encryption, = and > probably more things I haven't thought of yet. The goal of this list = is > certainly not to replace existing protocols or to change Internet > governance. >=20 > 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... >=20 > David >=20 > _______________________________________________ > Ilc mailing list > Ilc@ietf.org > https://www.ietf.org/mailman/listinfo/ilc --Apple-Mail=_932B6897-2D14-4158-97F9-1CF8195D48DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The fact that the term = consensus has a colloquial meaning may be
generating = confusion among some members of the list.

Which members? Bang them! >:-D

As = intended in the
list name, the term consensus refers to a = narrow distributed systems
definition, namely the problem = for a group of nodes to pick an input
value such that = there is both agreement (all nodes output the same
value) = and validity (the output equals one of the valid inputs, ruling
out vacuous solutions like always outputting zero). =  This is not to be
confused with other meanings of = the word, as in "rough consensus and
running code," or = consensus in any kind of a governance context.

I'm told they're fully aware of that.

Many kinds of = distributed system leverage some a consensus mechanism.
At = a high level, one of the things we might want to discuss in this list
is whether it could be beneficial for the IETF to standardize = some kind
of consensus protocol or = service.

As stated = before on this list [1, 2], and as stated elsewhere on the web in = semi-mathematical form [3,4], if such a consensus protocol or service is = used with Certificate Transparency or anything else related to DNS, that = would be to kill the Internet.

But you're welcome to work on a = consensus-agnostic protocol if your intentions are benevolent.

- Greg

[1] https://mailarchive.ietf.org/arch/msg/ilc/BmFgooRm5GikT6mwhx9yO= ZgL1G8
[2] https://mailarchive.ietf.org/arch/msg/ilc/tUirMiYqzIogI1S14qRKh= Y8Fz0E
[3] https://blog.bigchaindb.com/the-dcs-triangle-5ce0e9e0f1dc#.24de= xymvl
[4] https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fa= ll2016/blob/master/topics-and-advance-readings/Slepaks-Triangle.pdf

--
Please do not = email me anything that you are not comfortable also sharing with the = NSA.

On Feb 16, 2017, at 1:58 PM, dm-list-ietf-ilc@scs.stanford.edu wrote:

The = fact that the term consensus has a colloquial meaning may be
generating confusion among some members of the list.  As = intended in the
list name, the term consensus refers to a = narrow distributed systems
definition, namely the problem = for a group of nodes to pick an input
value such that = there is both agreement (all nodes output the same
value) = and validity (the output equals one of the valid inputs, ruling
out vacuous solutions like always outputting zero). =  This is not to be
confused with other meanings of = the word, as in "rough consensus and
running code," or = consensus in any kind of a governance context.

Many kinds of distributed system leverage some a consensus = mechanism.
At a high level, one of the things we might = want to discuss in this list
is whether it could be = beneficial for the IETF to standardize some kind
of = consensus protocol or service.  Such an effort could provide a = useful
building block for new or enhanced applications = such as Internet
payments, auditable software packages, = end-to-end email encryption, and
probably more things I = haven't thought of yet.  The goal of this list is
certainly not to replace existing protocols or to change = Internet
governance.

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...

David
_______________________________________________
Ilc mailing list
Ilc@ietf.org
https://www.ietf.org/mailman/listinfo/ilc

= --Apple-Mail=_932B6897-2D14-4158-97F9-1CF8195D48DF-- --Apple-Mail=_62B2D672-13B0-4852-8282-5CD13ADF4BB3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYpiQoAAoJEOxnICvpCVJHWYoQAMWaGMKD/kZyH+ZpZrjGwSdh KmhpRbQfI1AeA6pFbyGQ6NCPbDsl8bFN4myJOnhJ5j1BOcWsKlk5ddlANTLkPRz9 RqrGKdnLD1/EcDTJLLmtxSp39k4jevxH7b7aI74ND7THIcuRf+nRtoa9vWF+tyBX kdcpCY2rLK9G754RfVX8om3/Fcgtb7KbqQ/gn+E/QHPbbm/n7NymKwZ/tXcP45Ta 4FAHZm0p3yinQENTtapmHrxwKKF7AyXmHoP4h41P2bmqTE6o4DdG4PotgNsgT1WC AzRLsWi/Y/tLLoNrJFO1/OskgjcRZbATQiZw/AVxDvafYKBjXm1SmWRqw6rpZzvN oOZ67K/3dV7zfmMhsjDS/yvXfSg2gxr2lGP46kDSQEBH2RHlYKflutxQcq8RrzA4 DMi47proguwXAI2abMN4tyK7C2AGnXFslqsUSjOq6ohprN3ub6e5DdbOXzTa05T5 B2jUsbmcXMk5SheFsaIbh9CzEmXdsdK0aWA35umgE7iED3qcKvNsOEFB4HnjxTXl lauM09vdz/KnxnNcU9AVkHiz3mIMjIQyL5sVDJ2jf3+Lu9SXpnuxJ0Sa+M794RdV Qsb8Fzs4LRshTOt+YpBqgbqhZ+IYFyq2vAtPOuE39Ql37il9FpDar2HSqflKegWV M8LX+ue7jqb3bu0IVAAO =IIIW -----END PGP SIGNATURE----- --Apple-Mail=_62B2D672-13B0-4852-8282-5CD13ADF4BB3-- From nobody Fri Feb 17 05:58:50 2017 Return-Path: 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 2665B129A80 for ; Fri, 17 Feb 2017 05:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 wzRFhkvqk_po for ; Fri, 17 Feb 2017 05:58:47 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 3EE671299D2 for ; Fri, 17 Feb 2017 05:58:47 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id A1EAC280743; Fri, 17 Feb 2017 14:58:44 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 9BC99280735; Fri, 17 Feb 2017 14:58:44 +0100 (CET) Received: from b12.nic.fr (unknown [192.134.7.106]) by relay2.nic.fr (Postfix) with ESMTP id 99D38B38004; Fri, 17 Feb 2017 14:58:14 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 943524064A; Fri, 17 Feb 2017 14:58:14 +0100 (CET) Date: Fri, 17 Feb 2017 14:58:14 +0100 From: Stephane Bortzmeyer To: Tao Effect Message-ID: <20170217135814.zvhszwwelaulm436@nic.fr> References: <87mvdpon45.fsf@ta.scs.stanford.edu> <78FD9CB0-0DEC-4221-8D41-6A25E9027459@taoeffect.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78FD9CB0-0DEC-4221-8D41-6A25E9027459@taoeffect.com> X-Operating-System: Debian GNU/Linux 9.0 X-Kernel: Linux 4.8.0-2-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Cc: Tom Ritter , David Mazieres expires 2017-05-14 PDT , ilc@ietf.org Subject: Re: [Ilc] Welcome to the 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 13:58:49 -0000 On Thu, Feb 16, 2017 at 12:14:29PM -0800, Tao Effect wrote a message of 246 lines which said: > For this reason, it is also not secure. Anyone who can MITM a > network connection, can override apple.com The domain name or the URL (sorry for being picky but I find strange that people on an IETF mailing list confuse the two)? > to be anything they want, along with any other name in the insecure, This is not true. See RFC 4033, 4034 and 4035. From nobody Fri Feb 17 12:43:51 2017 Return-Path: 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 063D8129B07 for ; Fri, 17 Feb 2017 12:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=taoeffect.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 7NZ5uq8wtkwW for ; Fri, 17 Feb 2017 12:43:47 -0800 (PST) Received: from homiemail-a9.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420A21296BE for ; Fri, 17 Feb 2017 12:43:47 -0800 (PST) Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id DCA9E5BE070; Fri, 17 Feb 2017 12:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=u8oig0190wyO+Rh+F vlx/7TGgWY=; b=AId+9HLpBt0aKnlbOwCxQY9aruEo1c82KOzLxrrqMLR7lb7Or HaYsW4dsI8NsJ/507Og0eBfkT+Ctb/PirLVqYgDrdOHKISwzOPlvb+xu/0Em3KqH ykiKMefBUdAmsQGICyG0DykqtOR00USw1yqf0USnVR0LTR3d2Sl8P4E1fs= Received: from [192.168.42.64] (184-23-255-25.fiber.dynamic.sonic.net [184.23.255.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 8F3BD5BE06F; Fri, 17 Feb 2017 12:43:46 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C8B3A0B1-BA0E-41BF-8BDD-A20BECC3E0DF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Tao Effect In-Reply-To: <20170217135814.zvhszwwelaulm436@nic.fr> Date: Fri, 17 Feb 2017 12:43:44 -0800 X-Mao-Original-Outgoing-Id: 509057024.745201-eb6fe87f5af01a4f148d5beee67acfbc Message-Id: <0A83A3D6-3CF5-4F23-B84D-35B7DB7B1DFD@taoeffect.com> References: <87mvdpon45.fsf@ta.scs.stanford.edu> <78FD9CB0-0DEC-4221-8D41-6A25E9027459@taoeffect.com> <20170217135814.zvhszwwelaulm436@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Tom Ritter , David Mazieres expires 2017-05-14 PDT , ilc@ietf.org Subject: Re: [Ilc] Welcome to the 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 20:43:49 -0000 --Apple-Mail=_C8B3A0B1-BA0E-41BF-8BDD-A20BECC3E0DF Content-Type: multipart/alternative; boundary="Apple-Mail=_41D991CE-6BB2-44F7-9944-F7659AF45C96" --Apple-Mail=_41D991CE-6BB2-44F7-9944-F7659AF45C96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > This is not true. See RFC 4033, 4034 and 4035. RFC 6797 would have been a better choice as TLS is what actually secures = DNS, and DNSSEC/DANE are a joke [1], but even HSTS wouldn't help you = because almost no one uses it, including apple.com = [2]. [1] = https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md#dnsse= c = [2] = https://www.ssllabs.com/ssltest/analyze.html?d=3Dapple.com&s=3D17.178.96.5= 9&latest = - Greg -- Please do not email me anything that you are not comfortable also = sharing with the NSA. > On Feb 17, 2017, at 5:58 AM, Stephane Bortzmeyer > wrote: >=20 > On Thu, Feb 16, 2017 at 12:14:29PM -0800, > Tao Effect > = wrote > a message of 246 lines which said: >=20 >> For this reason, it is also not secure. Anyone who can MITM a >> network connection, can override apple.com = > >=20 > The domain name or the URL (sorry for being picky but I find strange > that people on an IETF mailing list confuse the two)? >=20 >> to be anything they want, along with any other name in the insecure, >=20 > This is not true. See RFC 4033, 4034 and 4035. --Apple-Mail=_41D991CE-6BB2-44F7-9944-F7659AF45C96 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
This is = not true. See RFC 4033, 4034 and 4035.

RFC 6797 would have been a better choice as TLS is = what actually secures DNS, and DNSSEC/DANE are a joke [1], but even = HSTS wouldn't help you because almost no one uses it, including apple.com [2].

[1] https://github.com/okTurtles/dnschain/blob/master/docs/Comparis= on.md#dnssec
[2] https://www.ssllabs.com/ssltest/analyze.html?d=3Dapple.com&= s=3D17.178.96.59&latest

- Greg

--
Please do not email me anything that you are not = comfortable also sharing with the NSA.

On Feb 17, 2017, at 5:58 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> = wrote:

On Thu, Feb 16, 2017 at 12:14:29PM -0800,
Tao = Effect <contact@taoeffect.com> wrote
a message = of 246 lines which said:

For this reason, it is also not secure. Anyone = who can MITM a
network connection, can override apple.com <http://apple.com/>

The domain name or the URL (sorry = for being picky but I find strange
that people on an IETF = mailing list confuse the two)?

to be anything they want, along with any other = name in the insecure,

This is = not true. See RFC 4033, 4034 and 4035.

= --Apple-Mail=_41D991CE-6BB2-44F7-9944-F7659AF45C96-- --Apple-Mail=_C8B3A0B1-BA0E-41BF-8BDD-A20BECC3E0DF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIbBAEBCgAGBQJYp2CAAAoJEOxnICvpCVJHB34P+PGoW6rUFhzOuufL8PTLhQhk 07Ycc3tMM0efYERqZLiAED0PkFQodrD/wUh9GHxLFHs/qNZhdEQxbfJ+2Fab3z14 1YNQEEzLJYF+1khZmuUECDBqUl5w8sxQkbUnfdrXlS2hTAbjjILhaTvxTlXiIs/Z T6Ev9rvflOlZv1kAJObx/038Ous2Hi9FlKzjkgB2v8e48yH9yaTak/S9DdcblukB F+f7lG9hmTlcU/IypJfVRQeaFUJ9g0UvxP2JXlEm2+5Ng8lm9O+u+6e3sRtI7BYK 4gUL3lojCwFmWRjKhQyfgLlVhe60UUOaZ8wqIM46bdFsvu2V5uZ8ZjG+93mr4RRL CRGFXkrsrZxfdm/llV5KVE3hrJzdLDRGzYa+TP8S97qbTzhz5v/TKN8Nb7U4mhat eQy1OS6lhSVXp0TrkwUwgGQm6JgdHpWyn1e3RtgZAfBnt58jKkKZC2cjMQUG4Kc0 HTPf7mUbhD/dwTcUD/wwDqXuvc6jUG5+9zUh4AW+9QQo/e2qbt584AGWfVE9hjB3 kFP3WGUtD8hjEPuJ+AymmqrX3bGRUV8XZh8wlfOmT9JW7XMDaWOHqhHxpy9PeFMg eon5UcusUm8efP94WetUJ7jiRnJ9g5NyARUt8xYO3paAi7eeOGZu1cEfUaAkpfHX XktsyPTYCaoIbw3tdtw= =JmfS -----END PGP SIGNATURE----- --Apple-Mail=_C8B3A0B1-BA0E-41BF-8BDD-A20BECC3E0DF-- From nobody Tue Feb 21 23:10:23 2017 Return-Path: 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 AB315129480 for ; Tue, 21 Feb 2017 23:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 CMORRdzxRO5C for ; Tue, 21 Feb 2017 23:10:20 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 EC81E129444 for ; Tue, 21 Feb 2017 23:10:19 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id j13so3052971iod.3 for ; Tue, 21 Feb 2017 23:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=7tI9rPkp5A8a8div2RijA0ejO9BnW4Ya6yAauKZpZgk=; b=Z2J233ukCYdJ4hx7ibga7zEk3WKw5SmG2Bbr4IvbqagR4zTs6YZw4LRVw5JkxHSxX1 Pai5ShhNNbOcClYXmwhfd0ClyUTWvSRhQPS3I1z5N7f5LwnkzoqdhZp9dSeGMT0zYk/a 1D1i0SzmnCht80PT2OVDblF8z6HKwwgtcEW6NME4EJtwM87/OnpGZk1h2PJ1xDwb7Ew+ ItPFuUZhLfGnUwch+dUIfP1lFWaA2gi0x3Pc/yRtvLy5ff3dJdNv4iPkkwVROdRSevXc ZOhOL8w5F2M+rdWD2NsGnEChf70OpBMpAOuddfUt2Yrltiea6SG9qCXPXgtUoGbyRYbe h0rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=7tI9rPkp5A8a8div2RijA0ejO9BnW4Ya6yAauKZpZgk=; b=gmaV1cFHiiQn3s0f0Dr6RlpEtKPHwyw01l2yTq0okCV7InlNQcLL8IjPCXtCqvvk6R hG//wCLMzHRcV7gABbymsn7NRzWynlnso3TIu89MbYT9YGkWo/MGzFgmufueoDhsr8MX JRNyaRRGyxSzhw2djJoAClwZz9LD+VMSh5jcP2VgYOCK0n/gHRuOiW6GxsPhQj2HHQnh sYwbf1VaVeWlVH3pdEgJE3bDiEmbhr7DpDYpmMx1M392diJtDRblfoo1CvTGzFyLXv/f EW6R6vcw0ro0BlfuHLu/VAnZI6ahg5t18cKEfj9oz16KpSLY6MBcZxWx5UuuMOsH/Ybl sNfA== X-Gm-Message-State: AMke39l+CLEa8jqrddvy9ET3ylvPsQdR6LVNGsw8gg5qtCwwS79T2Gk+8PJiMtseFxddrCazTOfwwQlqBem/tA== X-Received: by 10.107.10.11 with SMTP id u11mr25519952ioi.139.1487747419005; Tue, 21 Feb 2017 23:10:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.5.21 with HTTP; Tue, 21 Feb 2017 23:09:58 -0800 (PST) In-Reply-To: <87bmu194rx.fsf@ta.scs.stanford.edu> References: <87bmu194rx.fsf@ta.scs.stanford.edu> From: Tony Arcieri Date: Tue, 21 Feb 2017 23:09:58 -0800 Message-ID: Cc: ilc@ietf.org Content-Type: multipart/alternative; boundary=001a113ed60a6ce79605491930b5 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 07:10:22 -0000 --001a113ed60a6ce79605491930b5 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 16, 2017 at 1:58 PM, wrote: > The fact that the term consensus has a colloquial meaning may be > generating confusion among some members of the list. As intended in the > list name, the term consensus refers to a narrow distributed systems > definition, namely the problem for a group of nodes to pick an input > value such that there is both agreement (all nodes output the same > value) and validity (the output equals one of the valid inputs, ruling > out vacuous solutions like always outputting zero). > I strongly agree it's important to look at traditional definitions of consensus, particularly ideas like byzantine fault tolerance and CAP theorem/partition tolerance. > Does it make sense to leverage the permissionless aspects of the Internet > to implement some sort of permissionless consensus mechanism? While I think that would be interesting, the existing solutions in this space, namely Bitcoin-style proof-of-work chains, corrupt data under network partitions (so-called "blockchain forks", see also eclipse attacks) meaning they are not partition tolerant and therefore have neither CP nor AP semantics under CAP theorem (although CP semantics would be desirable), and have formally been demonstrated not to have the properties of byzantine fault tolerance[1] (BFT) or byzantine fault detection (BFD), which I would consider necessary in any sort of federated consensus system. Though the notion of "Satoshi consensus" has garnered a bit of attention due to Bitcoin, I hope any effort in this space is held to higher and more traditional standards of what "consensus" actually means in traditional distributed systems contexts, which includes not corrupting data in the presence of network partitions, and ideally possessing BFT or BFD semantics. So far, I am not aware of any feature-complete/deployed "permissionless" system that provides these properties. That's not saying they're impossible, but there's much groundwork that still needs to be done. Though I don't speak for Stellar (but have observed they appear to behind this BoF), I think they have been doing interesting work in this space with SCP, even if it compromises on the so-called "permissionless" aspect. That said, the Internet itself is a "permissioned" system (ASes can't peer willy nilly) as are many of the core protocols the Internet has been built on, and so far the sky hasn't fallen like certain chicken littles would tell you it will. Meanwhile the only "permissionless" system of note, Bitcoin, is having system-crippling issues with both scalability and governance, and appears to largely be under the control of mining cartels, so I'm not sure "permissionless" systems are necessarily a good idea or if they actually live up to the ideals of removing control of the system from a central cabal. At the end of the day systems need operators, and the operators will always be able to exert some degree of control. [1]: https://eprint.iacr.org/2014/765.pdf -- Tony Arcieri --001a113ed60a6ce79605491930b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 16, 2017 at 1:58 PM, <dm-list-ietf-ilc@scs.stanfo= rd.edu> wrote:
The fact that the term consensus has a colloquial meaning may be
generating confusion among some members of the list.=C2=A0 As intended in t= he
list name, the term consensus refers to a narrow distributed systems
definition, namely the problem for a group of nodes to pick an input
value such that there is both agreement (all nodes output the same
value) and validity (the output equals one of the valid inputs, ruling
out vacuous solutions like always outputting zero).
I strongly agree it's important to look at traditional def= initions of consensus, particularly ideas like byzantine fault tolerance an= d CAP theorem/partition tolerance.
=C2=A0
Does it make sense to leverage the permiss= ionless aspects of the Internet to=C2=A0
implement some sort of permissionless consensus= mechanism?

While I think that would be int= eresting, the existing solutions in this space, namely Bitcoin-style proof-= of-work chains, corrupt data under network partitions (so-called "bloc= kchain forks", see also eclipse attacks) meaning they are not partitio= n tolerant and therefore have neither CP nor AP semantics under CAP theorem= (although CP semantics would be desirable), and have formally been demonst= rated not to have the properties of byzantine fault tolerance[1] (BFT) or b= yzantine fault detection (BFD), which I would consider necessary in any sor= t of federated consensus system.

Though the notion= of "Satoshi consensus" has garnered a bit of attention due to Bi= tcoin, I hope any effort in this space is held to higher and more tradition= al standards of what "consensus" actually means in traditional di= stributed systems contexts, which includes not corrupting data in the prese= nce of network partitions, and ideally possessing BFT or BFD semantics. So = far, I am not aware of any feature-complete/deployed "permissionless&q= uot; system that provides these properties. That's not saying they'= re impossible, but there's much groundwork that still needs to be done.=

Though I don't speak for Stellar (but h= ave observed they appear to behind this BoF), I think they have been doing = interesting work in this space with SCP, even if it compromises on the so-c= alled "permissionless" aspect. That said, the Internet itself is = a "permissioned" system (ASes can't peer willy nilly) as are = many of the core protocols the Internet has been built on, and so far the s= ky hasn't fallen like certain chicken littles would tell you it will.

Meanwhile the only "permissionless" syste= m of note, Bitcoin, is having system-crippling issues with both scalability= and governance, and appears to largely be under the control of mining cart= els, so I'm not sure "permissionless" systems are necessarily= a good idea or if they actually live up to the ideals of removing control = of the system from a central cabal.

At the end of = the day systems need operators, and the operators will always be able to ex= ert some degree of control.


--
Tony Arcieri
--001a113ed60a6ce79605491930b5-- From nobody Wed Feb 22 10:25:15 2017 Return-Path: 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 8C891129973 for ; Wed, 22 Feb 2017 10:25:14 -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 eOOYHtFrP_HV for ; Wed, 22 Feb 2017 10:25:13 -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 3BD7B12967C for ; Wed, 22 Feb 2017 10:25:13 -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 v1MIPBL8099284; Wed, 22 Feb 2017 10:25:11 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1MIPBb6075971; Wed, 22 Feb 2017 10:25:11 -0800 (PST) From: David Mazieres To: Tony Arcieri In-Reply-To: References: <87bmu194rx.fsf@ta.scs.stanford.edu> Date: Wed, 22 Feb 2017 10:25:10 -0800 Message-ID: <87poiaf5h5.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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-23 PDT List-Id: "Discussion of mechanisms and applications for Internet-level consensus." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 18:25:14 -0000 Tony Arcieri writes: > While I think that would be interesting, the existing solutions in this > space, namely Bitcoin-style proof-of-work chains, corrupt data under > network partitions (so-called "blockchain forks", see also eclipse attacks) > meaning they are not partition tolerant and therefore have neither CP nor > AP semantics under CAP theorem (although CP semantics would be desirable), > and have formally been demonstrated not to have the properties of byzantine > fault tolerance[1] (BFT) or byzantine fault detection (BFD), which I would > consider necessary in any sort of federated consensus system. > > Though the notion of "Satoshi consensus" has garnered a bit of attention > due to Bitcoin, I hope any effort in this space is held to higher and more > traditional standards of what "consensus" actually means in traditional > distributed systems contexts, which includes not corrupting data in the > presence of network partitions, and ideally possessing BFT or BFD > semantics. So far, I am not aware of any feature-complete/deployed > "permissionless" system that provides these properties. That's not saying > they're impossible, but there's much groundwork that still needs to be done. Well, there are a bunch of different variants of Satoshi consensus. Some of them, like peercoin and tendermint, look more like traditional BFT, only where participants are elected based on some other criterion such as stake in a cryptocurrency. > Though I don't speak for Stellar (but have observed they appear to behind > this BoF), I think they have been doing interesting work in this space with > SCP, even if it compromises on the so-called "permissionless" aspect. That > said, the Internet itself is a "permissioned" system (ASes can't peer willy > nilly) as are many of the core protocols the Internet has been built on, > and so far the sky hasn't fallen like certain chicken littles would tell > you it will. > > ... > > At the end of the day systems need operators, and the operators will always > be able to exert some degree of control. I suppose one way of looking at the issue is that *all* consensus systems start to misbehave when owners of more then some fraction of some resource start misbehaving. Bitcoin breaks once about 1/3 of hashing power is controlled by someone with incentive to undermine the system. BFT breaks when 1/3 of nodes are malicious. Proof of stake breaks once too many coins elect Byzantine nodes. So maybe the question shouldn't be whether a system is permissioned or permissionless, but rather along what axis the permission lies. Another related question is how to balance safety (meaning agreement and validity, or roughly "CP semantics") against liveness (or "AP semantics" in CAP parlance)--as you can trade one off for the other--and how does that trade-off get decided. For better or for worse, the "currency" driving Internet change seems to be market clout. This is soft of a simplification of the point made by Clark et al. in "Tussle in Cyberspace," but basically change can happen because millions of end users adopt some protocol, or because systemically important ISPs unilaterally implement some change. The Stellar consensus protocol, SCP, was inspired by this model. It relies on something akin to market clout for consensus--individual nodes make their own trust decisions, and so "transitive trust" is really the resource that could allow someone to undermine the system. Not all aspects of the Internet are as robust as the ideal market-driven "tussle space." For example, TLS certificates have a disjunctive property, where a single CA can cause headaches for entities with much greater market clout. Moreover, it is difficult for individuals to adopt a CA for a particular purpose (like some set of websites) without it bleeding over into other purposes. Obviously the trans working group is improving the situation. Similarly, once you choose an email provider, your privacy is at the whim of that email provider even if, in aggregate, email providers would like to provide greater privacy. Finally, some things like payments between participants with no preexisting relationship just don't work today. This is one of the reasons Stellar developed SCP, and why I personally believe that some sort of standard Internet-level consensus would spur innovation that promotes financial inclusion. David From nobody Thu Feb 23 03:15:50 2017 Return-Path: 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 6CDEF1296C7 for ; Thu, 23 Feb 2017 03:15:48 -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 iUbKpFWvy2bj for ; Thu, 23 Feb 2017 03:15:46 -0800 (PST) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 0EAD81296AB for ; Thu, 23 Feb 2017 03:15:46 -0800 (PST) Received: by mail-wr0-x232.google.com with SMTP id 97so19637096wrb.0 for ; Thu, 23 Feb 2017 03:15:45 -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=5VwPjKeA+TihKXzKrAfDeRbPPeOZ8TDqJY8Xt6bGjhg=; b=PfAGXESAQVNdXF+hy9eU2r8mScGmeMTL3uElxoTssxFPT4hll2L9V5SJDN9iNkrRXk 7QAz2WFXG0WVuBxiBj4ADxcGfWtD0cVw23mM69F4WIXbC0BmzzBTIDEYOnunxOB6/e2V Vt2gti7OmXBnOkDD4nyBza/79lmlrPmk5fDAQstJFPjPG3mrq1RlpUdBKQ5xs4ZKFCiG sBLa8KAHcVSgk22pjug4u9U5ONy0kw0YGu2lsnH71IQGloe6hPqWm/G6s9r4AFLFlV5u +HUDQI89HWCN5PyKcdlF0duDHbOUT9uIwEzl/t2ClzosM5iCahrHFtfHopJpnnTqVv+Q hJtA== 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=5VwPjKeA+TihKXzKrAfDeRbPPeOZ8TDqJY8Xt6bGjhg=; b=D8+g2DOBUTFnjuVKwfecK0E3cOdgxMgtc7zLMrpywK0hxS8ovF/XSNSkYw+yBhR+UU ugV5wlfRcLlUUm36iSiF1h8gzt36TYn3q28Vio6yDcegj/5RRoOouNTrq0/rXr0h2fei P5erl4ojisEvluUhxY2lwpDBnlGOGNGKAOxMXfcmkIoG3rSf+UsOvXmLe4fv2gVaOz2l YqAE/O/fYmWmT4w3Qotq3/0ordV72atxVAokZstJVzL3NhHHiP1uVvqkiqi7Hr4/QBDd nqveoVFawCaIL9qD5XUuO8mQPQem9anFwhZfI1V7+GZot02fXXTRunO7r7j7R2JYI7LV /L9g== X-Gm-Message-State: AMke39neNTHL87VDeTHuU+oOy3047KNMv+SgpRO0KMNg5CjgI9dHZiZoO+LMtywjCMzUqWvL/81g4CBhQ6zCYg== X-Received: by 10.223.170.146 with SMTP id h18mr6138wrc.113.1487848544278; Thu, 23 Feb 2017 03:15:44 -0800 (PST) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.28.180.7 with HTTP; Thu, 23 Feb 2017 03:15:43 -0800 (PST) In-Reply-To: <87bmu194rx.fsf@ta.scs.stanford.edu> References: <87bmu194rx.fsf@ta.scs.stanford.edu> From: Ben Laurie Date: Thu, 23 Feb 2017 11:15:43 +0000 X-Google-Sender-Auth: kBhOUUNitVa4qzU_O4VMGtrzDHE Message-ID: To: David Mazieres expires 2017-05-17 PDT Content-Type: text/plain; charset=UTF-8 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 11:15:48 -0000 On 16 February 2017 at 21:58, wrote: > The fact that the term consensus has a colloquial meaning may be > generating confusion among some members of the list. As intended in the > list name, the term consensus refers to a narrow distributed systems > definition, namely the problem for a group of nodes to pick an input > value such that there is both agreement (all nodes output the same > value) and validity (the output equals one of the valid inputs, ruling > out vacuous solutions like always outputting zero). This is not to be > confused with other meanings of the word, as in "rough consensus and > running code," or consensus in any kind of a governance context. > > Many kinds of distributed system leverage some a consensus mechanism. > At a high level, one of the things we might want to discuss in this list > is whether it could be beneficial for the IETF to standardize some kind > of consensus protocol or service. Such an effort could provide a useful > building block for new or enhanced applications such as Internet > payments, auditable software packages, end-to-end email encryption, and > probably more things I haven't thought of yet. The goal of this list is > certainly not to replace existing protocols or to change Internet > governance. > > 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. 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). 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. > > David > > _______________________________________________ > Ilc mailing list > Ilc@ietf.org > https://www.ietf.org/mailman/listinfo/ilc From nobody Thu Feb 23 09:36:13 2017 Return-Path: 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 06BB112A202 for ; Thu, 23 Feb 2017 09:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 VFMeaRMI44NP for ; Thu, 23 Feb 2017 09:36:11 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 D9FD9129A6A for ; Thu, 23 Feb 2017 09:36:10 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id h10so174030707ith.1 for ; Thu, 23 Feb 2017 09:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XNA4VO5h6ebzMry7lhQZdYNtEWS7WEgX8B66zGJbmS4=; b=MvN1c4jPB0v8vY7DEPkACSPDolQwh2eExmzp2MXrbdtaVMpmcZLyLtPyAflQP7/Rva BgUPmbnmq2OjdeB4cYHUGkqL+3Au0qULr1SQfSii8LARkfsMFEGueqOWplN0uPPb+tRb TkfgeeEgiO7mH8LDPVLDTdhY7B/ulGHgmeRHjMf95+ivG6sZlD9edzT6YMiQIkidFA0Q tyMKPe5SfO35CEM1KUmaio2TjPYig4rL69meuKIniyl5mnzl9IYtfSfLq+Sjc1Go8Qd3 G4mTHzOO0aV41NhhOzgTTWWQCeLMenB3Kkg1oD3fpXc4ObAir/+Jx3jkC+umTOZTBYEv zlKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XNA4VO5h6ebzMry7lhQZdYNtEWS7WEgX8B66zGJbmS4=; b=IzDKPs07kAKxsP4GMnJMbHIeoFBhaMIxO4UT5In8topdlI5FTDjmqXXQZYNPAcSRtl 1PdKbAYFxq1v3OUXGVTn9j7xyWITVGVGkIM/uQP7hhh9nZFt+Czgu8Gffvh3q9X298bq uELMTdiSBF5VzcKFP5teUaLLq3FlxmVaiiZAsrNY7ZJcyU4bkg2eH1NL80svxHCXYVip wGzu9v/0hUHamcnU6ZEVEsJTu72vpNHsIZe7q7ohl09X/WywkR14nLcQGHzbFn0wbjlk RyWtlfigY4f/YhPnYKdVH+9r105wduLCex6yasGOW7PF4WXRTg3JTy2TL3EnvNI6npxN R9xQ== X-Gm-Message-State: AMke39kkb5o5DteU8T3J/VFbyJDsiXw61kSUc7/MQJ34/V/czfUhzrG2N4lusitdJMlFhktPd3zJXYaE26HgRA== X-Received: by 10.36.127.73 with SMTP id r70mr3855044itc.11.1487871370184; Thu, 23 Feb 2017 09:36:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.5.21 with HTTP; Thu, 23 Feb 2017 09:35:49 -0800 (PST) In-Reply-To: <87poiaf5h5.fsf@ta.scs.stanford.edu> References: <87bmu194rx.fsf@ta.scs.stanford.edu> <87poiaf5h5.fsf@ta.scs.stanford.edu> From: Tony Arcieri Date: Thu, 23 Feb 2017 09:35:49 -0800 Message-ID: To: David Mazieres expires 2017-05-23 PDT Content-Type: multipart/alternative; boundary=001a1147c5ae7ddda00549360ca0 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 17:36:12 -0000 --001a1147c5ae7ddda00549360ca0 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 22, 2017 at 10:25 AM, David Mazieres < dm-list-ietf-ilc@scs.stanford.edu> wrote: > Well, there are a bunch of different variants of Satoshi consensus. > Some of them, like peercoin and tendermint, look more like traditional > BFT, only where participants are elected based on some other criterion > such as stake in a cryptocurrency. Like many things in this space, "Satoshi consensus" is an ill-defined buzzword. In part I think it means incorporating programs into the consensus decision, which seems like fairly novel and interesting work to me (and somewhat similar to e.g. Trillian's "personalities"). In this space, yes incorporating consensus programs into (P)BFT-like schemes such as Tendermint is interesting. However, above I was using it specifically to refer to the proof-of-work scheme for consensus. "CP" versus "AP" of course both assume "P", a property Bitcoin (and systems using a similar proof-of-work consensus model) do not have. Under a network partition in Bitcoin, the system will both make progress and be available for reading (where CP systems will fail closed if they can't reach a quorum). When the partition is healed, acknowledge writes are lost and data is clobbered. Systems which truly uphold "CP" or "AP" semantics do not clobber data this way. This sort of split-brain behavior can be exploited by attackers who are able to arbitrarily create network partitions. Eclipse attacks are a common example. -- Tony Arcieri --001a1147c5ae7ddda00549360ca0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 22, 2017 at 10:25 AM, David Mazieres <dm-list-iet= f-ilc@scs.stanford.edu> wrote:
Well, there are a bunch of different variants of Satoshi consensus.
Some of them, like peercoin and tendermint, look more like traditional
BFT, only where participants are elected based on some other criterion
such as stake in a cryptocurrency.

Like man= y things in this space, "Satoshi consensus" is an ill-defined buz= zword. In part I think it means incorporating programs into the consensus d= ecision, which seems like fairly novel and interesting work to me (and some= what similar to e.g. Trillian's "personalities"). In this spa= ce, yes incorporating consensus programs into (P)BFT-like schemes such as T= endermint is interesting.

However, above I was usi= ng it specifically to refer to the proof-of-work scheme for consensus. &quo= t;CP" versus "AP" of course both assume "P", a pro= perty Bitcoin (and systems using a similar proof-of-work consensus model) d= o not have. Under a network partition in Bitcoin, the system will both make= progress and be available for reading (where CP systems will fail closed i= f they can't reach a quorum). When the partition is healed, acknowledge= writes are lost and data is clobbered. Systems which truly uphold "CP= " or "AP" semantics do not clobber data this way.
=
This sort of split-brain behavior can be exploited by attack= ers who are able to arbitrarily create network partitions. Eclipse attacks = are a common example.

--
Tony Arcieri
--001a1147c5ae7ddda00549360ca0-- From return-zxm4cympmjkzjumfe4jz6nbt2e@temporary-address.scs.stanford.edu Thu Feb 23 10:35:59 2017 Return-Path: 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 5DA5212968B for ; Thu, 23 Feb 2017 10:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1RgRAj6nl-rY for ; Thu, 23 Feb 2017 10:35:58 -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 EADA81295F3 for ; Thu, 23 Feb 2017 10:35:57 -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 v1NIZvme040116; Thu, 23 Feb 2017 10:35:57 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1NIZu6o022617; Thu, 23 Feb 2017 10:35:56 -0800 (PST) From: David Mazieres To: Ben Laurie In-Reply-To: References: <87bmu194rx.fsf@ta.scs.stanford.edu> Date: Thu, 23 Feb 2017 10:35:56 -0800 Message-ID: <878towah6b.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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-24 PDT List-Id: "Discussion of mechanisms and applications for Internet-level consensus." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:15:28 -0000 Ben Laurie 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. > 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 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. 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. David From nobody Thu Feb 23 11:25:46 2017 Return-Path: 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 1E1F21296B4 for ; Thu, 23 Feb 2017 11:25:45 -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 kkn8glCHz0NZ for ; Thu, 23 Feb 2017 11:25:44 -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 211FB129982 for ; Thu, 23 Feb 2017 11:25:44 -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 v1NJPhxD015528; Thu, 23 Feb 2017 11:25:43 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1NJPhxm036962; Thu, 23 Feb 2017 11:25:43 -0800 (PST) From: David Mazieres To: Tony Arcieri In-Reply-To: References: <87bmu194rx.fsf@ta.scs.stanford.edu> <87poiaf5h5.fsf@ta.scs.stanford.edu> Date: Thu, 23 Feb 2017 11:25:43 -0800 Message-ID: <87ino0d808.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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-24 PDT List-Id: "Discussion of mechanisms and applications for Internet-level consensus." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:25:45 -0000 Tony Arcieri writes: > Like many things in this space, "Satoshi consensus" is an ill-defined > buzzword. In part I think it means incorporating programs into the > consensus decision, which seems like fairly novel and interesting work to > me (and somewhat similar to e.g. Trillian's "personalities"). In this > space, yes incorporating consensus programs into (P)BFT-like schemes such > as Tendermint is interesting. Okay, then by that definition, "Satoshi consensus" is only one possible approach among several to realizing Internet-level consensus. > However, above I was using it specifically to refer to the proof-of-work > scheme for consensus. "CP" versus "AP" of course both assume "P", a > property Bitcoin (and systems using a similar proof-of-work consensus > model) do not have. Under a network partition in Bitcoin, the system will > both make progress and be available for reading (where CP systems will fail > closed if they can't reach a quorum). When the partition is healed, > acknowledge writes are lost and data is clobbered. Systems which truly > uphold "CP" or "AP" semantics do not clobber data this way. I agree about CP, but not AP. AP systems are not safe, and hence will clobber data. Perhaps CAP is not the best way to categorize these systems, though. It may be better just to assume an asynchronous communication model (which subsumes temporary partitions as equivalent to slow nodes). Then we can just talk about safety (agreement + validity), liveness (termination), and fault tolerance. > This sort of split-brain behavior can be exploited by attackers who are > able to arbitrarily create network partitions. Eclipse attacks are a common > example. Right, so basically you are saying any Internet-level consensus mechanism should guarantee safety even in an asynchronous communication model where you can't distinguish slow from failed nodes. I agree, personally. However, reasonable people might push for greater availability. It would be interesting to see if list members have "rough consensus" (non-technical meaning) on this point, or alternatively if makes sense to layer a less safe but more available "short-term" system on top of one that guarantees safety for long-term events (e.g., for certificates issued over a week ago). We may want to revisit this question down the line after discussing more applications. David From nobody Thu Feb 23 11:38:43 2017 Return-Path: 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 C31B3129A4A for ; Thu, 23 Feb 2017 11:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 yskioyCSv0lq for ; Thu, 23 Feb 2017 11:38:39 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 60D7B12996D for ; Thu, 23 Feb 2017 11:38:39 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id y135so15273973itc.1 for ; Thu, 23 Feb 2017 11:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9FpEe/O12lV60bagn9dmmaBmoku7XgbVz3qYwFxHUb0=; b=ZfKZ+NxG/A4AvgIdrGystM56deq78m80QX4kl+OgUyorc9rU0O3XKD0OTD+u1w9ryP yflK77U/MeXnd3zn28AGaRLsHqHomB9R16gBHkmZVfxPyCGIOtp5qvGx6GpRsbEc0Z/n QUPkiaL34Y0DY6QhXiv3LgdPGGCK8dh+1xPV6lSjLpGrztyiYweD6QNq3l3j+++EFYqs 76p0Kw2HWEc6lWWQTvGgv274hr/LtiYeg94jmU8R92AS7rW2gPPkNXfr9iLhmoQsIiYS ehHHBdIgCtMNpFxVGerSB6p90jt8iApgzdJ4syzMRDx5/XY4yRPo2lCnNJIGLYuvsOl4 8yoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9FpEe/O12lV60bagn9dmmaBmoku7XgbVz3qYwFxHUb0=; b=YCBmBYaEa05yj7Smdt9RriZKChyiz+H8Pvf9c9Vg3lgUr8U3/OVXOO8uWjLBRIqhuk kEZhTlN1wL89xbb5r3MGAqbpbjsGv08VvolSUo04hWoomPMNBDXKNQBTIy8CGJYRXPuA 62Ciamd+V9Dado12rfFVfB/SqwybhSWtybbwSV1o11ZFwf/0KLqZlfrNAv0FC+NIEkfX AAqXZhgAP6XS8bcAhrCfnMxIfwxqUctYvakhWggLMXyRIXv9ntEC2XULNA7RjgDP01Q6 taENeEBEY1DnnPcOd8ZvsFMcNUeQV17+JDkCe0yfiF7mbNaot8s9eJpv8gdBAYdQzQkT scKw== X-Gm-Message-State: AMke39m3AqNFkQICs+2GzJ6WubpQ79+pryFfU3YBy1iwNq3fC3z2E5cYC6/QyD7bs9J64g2mWHMNp5PBj+KJLQ== X-Received: by 10.107.10.11 with SMTP id u11mr33308230ioi.139.1487878718771; Thu, 23 Feb 2017 11:38:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.5.21 with HTTP; Thu, 23 Feb 2017 11:38:18 -0800 (PST) In-Reply-To: <87ino0d808.fsf@ta.scs.stanford.edu> References: <87bmu194rx.fsf@ta.scs.stanford.edu> <87poiaf5h5.fsf@ta.scs.stanford.edu> <87ino0d808.fsf@ta.scs.stanford.edu> From: Tony Arcieri Date: Thu, 23 Feb 2017 11:38:18 -0800 Message-ID: To: David Mazieres expires 2017-05-24 PDT Content-Type: multipart/alternative; boundary=001a113ed60a80594f054937c236 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:38:41 -0000 --001a113ed60a80594f054937c236 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 23, 2017 at 11:25 AM, David Mazieres < dm-list-ietf-ilc@scs.stanford.edu> wrote: > I agree about CP, but not AP. AP systems are not safe, and hence will > clobber data. > Correctly designed AP systems support a merge operation to reconcile disparate states. CRDTs are an example of a system that can always merge data automatically in a conflict-free manner. In absence of that you need a domain-specific user defined merge function. That said Last Writer Wins is a popular strategy in systems describing themselves as AP, and exhibits this sort of data clobbering behavior. I'm not sure such systems should describe themselves as partition tolerant, though. Right, so basically you are saying any Internet-level consensus > mechanism should guarantee safety even in an asynchronous communication > model where you can't distinguish slow from failed nodes. I agree, > personally. However, reasonable people might push for greater > availability. It would be interesting to see if list members have > "rough consensus" (non-technical meaning) on this point, or > alternatively if makes sense to layer a less safe but more available > "short-term" system on top of one that guarantees safety for long-term > events (e.g., for certificates issued over a week ago). We may want to > revisit this question down the line after discussing more applications. The main option, which is particularly applicable to systems which publish to read-only clients, is to allow stale reads. This flips the semantics from CP to AP, allowing inconsistent views of the current state of the data (i.e. sacrificing consistency for availability), but should be safe if data being read is not incorporated into subsequent writes (i.e. stale reads are only allowed by truly read-only clients) -- Tony Arcieri --001a113ed60a80594f054937c236 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 23, 2017 at 11:25 AM, David Mazieres <dm-list-iet= f-ilc@scs.stanford.edu> wrote:
I agree about CP, but not AP.=C2=A0 AP systems are not safe, and hence = will
clobber data.

Correctly designed AP sys= tems support a merge operation to reconcile disparate states. CRDTs are an = example of a system that can always merge data automatically in a conflict-= free manner. In absence of that you need a domain-specific user defined mer= ge function.

That said Last Writer Wins is a popul= ar strategy in systems describing themselves as AP, and exhibits this sort = of data clobbering behavior. I'm not sure such systems should describe = themselves as partition tolerant, though.=C2=A0

Right, so basically you are saying any Internet-lev= el consensus
mechanism should guarantee safety even in an asynchronous communication
model where you can't distinguish slow from failed nodes.=C2=A0 I agree= ,
personally.=C2=A0 However, reasonable people might push for greater
availability.=C2=A0 It would be interesting to see if list members have
"rough consensus" (non-technical meaning) on this point, or
alternatively if makes sense to layer a less safe but more available
"short-term" system on top of one that guarantees safety for long= -term
events (e.g., for certificates issued over a week ago).=C2=A0 We may want t= o
revisit this question down the line after discussing more applications.

The main option, which is particularly applica= ble to systems which publish to read-only clients, is to allow stale reads.= This flips the semantics from CP to AP, allowing inconsistent views of the= current state of the data (i.e. sacrificing consistency for availability),= but should be safe if data being read is not incorporated into subsequent = writes (i.e. stale reads are only allowed by truly read-only clients)
=

--
Tony Arcieri
--001a113ed60a80594f054937c236-- From nobody Thu Feb 23 12:03:39 2017 Return-Path: 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 C70311299F9 for ; Thu, 23 Feb 2017 12:03:37 -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 Mt73ZP0oazTQ for ; Thu, 23 Feb 2017 12:03:36 -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 EABF4129853 for ; Thu, 23 Feb 2017 12:03:36 -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 v1NK3aD1058239; Thu, 23 Feb 2017 12:03:36 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1NK3a2w088645; Thu, 23 Feb 2017 12:03:36 -0800 (PST) From: dm-list-ietf-ilc@scs.stanford.edu To: Tony Arcieri In-Reply-To: References: <87bmu194rx.fsf@ta.scs.stanford.edu> <87poiaf5h5.fsf@ta.scs.stanford.edu> <87ino0d808.fsf@ta.scs.stanford.edu> Date: Thu, 23 Feb 2017 12:03:36 -0800 Message-ID: <87bmtsd693.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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-24 PDT List-Id: "Discussion of mechanisms and applications for Internet-level consensus." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 20:03:38 -0000 Tony Arcieri writes: > Correctly designed AP systems support a merge operation to reconcile > disparate states. CRDTs are an example of a system that can always merge > data automatically in a conflict-free manner... > > ... > > The main option, which is particularly applicable to systems which publish > to read-only clients, is to allow stale reads. This flips the semantics > from CP to AP, allowing inconsistent views of the current state of the data > (i.e. sacrificing consistency for availability), but should be safe if data > being read is not incorporated into subsequent writes (i.e. stale reads are > only allowed by truly read-only clients) Ah, so I agree with the points you are making, I just think they are at a different level of abstraction from the consensus mechanism. In other words, I can take a safe consensus protocol and use it to implement a secure read-only log. That log abstraction might support an operation along the lines of "verify that some log prefix satisfies some predicate," which one might then use to check that a particular transaction committed, or to get a recent value of some variable without necessarily knowing the latest. So the question is not "are weak consistency models useful for systems?" to which the answer would be an obvious yes. The question is what, if any, support would weakly consistent systems require from an underlying Internet-level consensus protocol? My preference would be to answer "none," because I worry such support would complicate reasoning about the safety of strongly consistent systems. But that's obviously a good topic for discussion on this list. David From nobody Thu Feb 23 14:38:05 2017 Return-Path: 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 ; 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 ; 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 ; Thu, 23 Feb 2017 14:38:00 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id 89so2779601wrr.3 for ; 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> <878towah6b.fsf@ta.scs.stanford.edu> From: Ben Laurie Date: Thu, 23 Feb 2017 22:37:58 +0000 X-Google-Sender-Auth: lvMGbBdehazp_Kd1Yn09UPMz9og Message-ID: To: David Mazieres expires 2017-05-24 PDT Content-Type: text/plain; charset=UTF-8 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 22:38:03 -0000 On 23 February 2017 at 18:35, David Mazieres wrote: > Ben Laurie 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. :-) From nobody Thu Feb 23 15:06:57 2017 Return-Path: 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 7C8E4129C24 for ; Thu, 23 Feb 2017 15:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 COdfpbt9aAnq for ; Thu, 23 Feb 2017 15:06:55 -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 24446129B9B for ; Thu, 23 Feb 2017 15:06:55 -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 v1NN6soO003582; Thu, 23 Feb 2017 15:06:54 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v1NN6sRR020805; Thu, 23 Feb 2017 15:06:54 -0800 (PST) From: David Mazieres To: Ben Laurie In-Reply-To: References: <87bmu194rx.fsf@ta.scs.stanford.edu> <878towah6b.fsf@ta.scs.stanford.edu> Date: Thu, 23 Feb 2017 15:06:54 -0800 Message-ID: <87zihcbj75.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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-24 PDT List-Id: "Discussion of mechanisms and applications for Internet-level consensus." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 23:06:56 -0000 Ben Laurie writes: >> 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? Well, there is a cartoon guide, but I don't actually think it will be useful in this context: https://www.stellar.org/stories/adventures-in-galactic-consensus-chapter-1/ 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 > 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. 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. > a) it seems utterly disconnected with the standard view of > "permissionless", so I think real care is needed with the charter. I think the term permissionless may just not be useful in this context, because even though it has been used to describe systems related to Internet-level consensus, there are other potential solutions that don't fit the permissioned/permissionless binary model. > 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. 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. 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. Thanks, David From nobody Sun Feb 26 13:25:28 2017 Return-Path: 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 BC0F0129459 for ; Sun, 26 Feb 2017 13:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 kW2uR_FgOkOB for ; Sun, 26 Feb 2017 13:25:26 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 BF8BC129457 for ; Sun, 26 Feb 2017 13:25:25 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id u199so5401374wmd.1 for ; Sun, 26 Feb 2017 13:25:25 -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=1AHsWeLFbrPuahxog3KCiP3BX1iqZCARAnBM2qcvAZE=; b=BkHGAFODk67+0WCH69EyhH8hNLNis7vlpjzCjGQ/q+sF35pa7r5ZfIL94dJetm9AHl iMJK9W4Lbm8FGb9RYuvzblUM/VIb4o7SB3bckk8/CjvHJoSkcKbEQRU5miVCmowkyfVK LqQLT+GNj9o+I7ddoY6dlasQWFRpSnsE9zk+gHl42CVmyoJo07XESi/mNg3nhSuhJ2SR M1hP0JKwPXN9Jg2N9z9ey8PNKsU4oEG3NdQBi/k8MCd5p0o1x0e2j54v3rRZHTILBNJf tnyYavlEYyGv/KD6xcKzpdLKnMYx8NYo/W412ndpyYJ6ZdtDsFA96ihACca+Z6CB8UhQ PRTw== 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=1AHsWeLFbrPuahxog3KCiP3BX1iqZCARAnBM2qcvAZE=; b=lEi8nT5xGrgjxbbSbAw9in2trLzoTrJzNms91NEBnHRM3EoDLH7uacMq6oSorG07XX ioOn3eXvOW2adkUCVQwpOsYn7iQUlwQG9ylFc1jEEFf8zHhoR9Bl3sr4WEp6OodYJHv9 Nhi6jXBgl9/fpWYUwxe1ggah0GZCSa687NqynX5zixK9hJBwmKAI2Ka3tL3jxVKvuJQ6 sMBgjbxd8OxN15L3i+32bGEc9Mwtul2rn4GBFTMT94KAKM0M5m2ag8f74JeZrG1Iud70 R8tvX4Af4B27iC+uhNFqab1KEoTxe3CRbBrEO7A6k4vf4xsncjkfpC0KBxwPBuhO+1bK G1Qw== X-Gm-Message-State: AMke39mvj9eFhoVHCwrTXlAHuhm75uZgYxIsj3MuHZynDx6iErlDKwKjqSwiksA6CFfsM+XXhyz0xXUZMW0O1Q== X-Received: by 10.28.134.67 with SMTP id i64mr10438363wmd.5.1488144324168; Sun, 26 Feb 2017 13:25:24 -0800 (PST) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.28.166.208 with HTTP; Sun, 26 Feb 2017 13:25:23 -0800 (PST) In-Reply-To: <87zihcbj75.fsf@ta.scs.stanford.edu> References: <87bmu194rx.fsf@ta.scs.stanford.edu> <878towah6b.fsf@ta.scs.stanford.edu> <87zihcbj75.fsf@ta.scs.stanford.edu> From: Ben Laurie Date: Sun, 26 Feb 2017 21:25:23 +0000 X-Google-Sender-Auth: 9GLwQdE1Jm4DXC9E__0VvhvkNw8 Message-ID: To: David Mazieres expires 2017-05-24 PDT Content-Type: text/plain; charset=UTF-8 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 21:25:27 -0000 On 23 February 2017 at 23:06, David Mazieres wrote: > Ben Laurie writes: > >>> 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? > > Well, there is a cartoon guide, but I don't actually think it will be > useful in this context: > > https://www.stellar.org/stories/adventures-in-galactic-consensus-chapter-1/ Well, its fun. > 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. > >> 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. > > 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. >> a) it seems utterly disconnected with the standard view of >> "permissionless", so I think real care is needed with the charter. > > I think the term permissionless may just not be useful in this context, > because even though it has been used to describe systems related to > Internet-level consensus, there are other potential solutions that don't > fit the permissioned/permissionless binary model. Agree. > >> 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. > > 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. > > 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. > > Thanks, > David From nobody Mon Feb 27 18:22:41 2017 Return-Path: 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 ; 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 ; 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 ; 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 To: Ben Laurie In-Reply-To: References: <87bmu194rx.fsf@ta.scs.stanford.edu> <878towah6b.fsf@ta.scs.stanford.edu> <87zihcbj75.fsf@ta.scs.stanford.edu> 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: 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 List-Id: "Discussion of mechanisms and applications for Internet-level consensus." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 02:22:40 -0000 Ben Laurie 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 From nobody Tue Feb 28 13:04:18 2017 Return-Path: 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 118371296FD for ; Tue, 28 Feb 2017 13:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 6ETkZWqXtCGg for ; Tue, 28 Feb 2017 13:04:15 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 5BFFC129702 for ; Tue, 28 Feb 2017 13:04:15 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id u48so17143746wrc.0 for ; Tue, 28 Feb 2017 13:04:15 -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=3tcAllgF+UjTeOaGis/PexoopTI2Q7temIfwU3aoKhg=; b=jp5iwi8X9Mgk8+WDVB6CuwnHPQzaZrHy1AuNUXpHvb7TnSbhdRfvedbP/+bRjQRRdU kVJKDB7st0/iNyTDDH5VIIbTTzhtGm0gRROgHNv+VaT4yAD749akjts1znok6uKczH/K f2fVSIZgVXSEF8FyfjAZ+wVtpCiJLrIZJuvnzF+xpnMLK1YABjHI/VBRF9dN3rYxS+5Q lL0zdUIu6rXtvFnHGFmHLT2OINeqcmmpQHyYyo4j/YTVDq8uxGHChPXpYgGqwHwJ5/K7 cgpu3ivbOHP+BTm/NFhOB5C4fAESF4d9CfT+edmi17h0S6Kk1jLdqFkAIrx+iyMAnq11 /mKg== 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=3tcAllgF+UjTeOaGis/PexoopTI2Q7temIfwU3aoKhg=; b=Kf/imVni9s3I01Mhwy+FPfdTNPXbU/p7y3eGFC/miHogVKbt7snNEK4Ek2PmOMNP6u 1VG/7C6mbonjFPMgB2SMwauN3TLaco5g3F1p9q32UMRc5fILp5IfJBlQuCuKH7SJYtie 1sMkOJlB0nxw7xrKJrWL22TQi9e2sxUyeiA3rPZwrXPLSGvjn2E2WuITKkWHKdTldD68 N9EKJudSb6y0amG0obfKgjHfRhhnw+90intJA0jc3XwlUbn2gE3VFV1ArndXWvEFWO7c ZDuc/exIQycHFwYhN20ri89yi+Fcj9o3M1/JcbdFNouHHZdB83L4KUpxJfcvOP3t5z2X /WPQ== X-Gm-Message-State: AMke39nKNOrtJs//agf5Mi9RJcW6syqjFFPUTKtyMMxhGYCkYfARRmSoqyG5f2AiB3eDkHKkBrUfLZVRpcIAoQ== X-Received: by 10.223.170.146 with SMTP id h18mr3745313wrc.113.1488315853663; Tue, 28 Feb 2017 13:04:13 -0800 (PST) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.28.166.208 with HTTP; Tue, 28 Feb 2017 13:04:13 -0800 (PST) In-Reply-To: <87mvd79hqt.fsf@ta.scs.stanford.edu> References: <87bmu194rx.fsf@ta.scs.stanford.edu> <878towah6b.fsf@ta.scs.stanford.edu> <87zihcbj75.fsf@ta.scs.stanford.edu> <87mvd79hqt.fsf@ta.scs.stanford.edu> From: Ben Laurie Date: Tue, 28 Feb 2017 21:04:13 +0000 X-Google-Sender-Auth: _Fi4JDPXNiINN98lL9EPwtv1g-s Message-ID: To: David Mazieres expires 2017-05-28 PDT Content-Type: text/plain; charset=UTF-8 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:04:17 -0000 On 28 February 2017 at 02:22, David Mazieres wrote: > Ben Laurie 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. OK, but that seems equally doable with a CT-like mechanism. The EFF either constructs its own version of the RedHat and Debian logs, or, much more efficiently, keeps a log of their log heads... > >>> 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. Thinking about this again, I'm not quite sure what you mean here: a threshold of what? Logs of certificate issuance? I don't see how that would prevent a CA issuing any cert it wants? >>> 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." Global consensus would help CT by providing a mechanism that prevents CT logs forking. >>> 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 screws people who lost their keys, though - and, as you say, new owners of domains. And since those will be the usual cases, the only person it doesn't screw is the MITM. And is pretty much orthogonal to consensus (other than the log forking problem). > 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