From nobody Thu Mar 9 14:07:08 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 D7559129588; Thu, 9 Mar 2017 14:07:04 -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 2eheyJgeQA7P; Thu, 9 Mar 2017 14:07:04 -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 18131129490; Thu, 9 Mar 2017 14:07:04 -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 v29M73Tv063696; Thu, 9 Mar 2017 14:07:03 -0800 (PST) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v29M73oT056087; Thu, 9 Mar 2017 14:07:03 -0800 (PST) From: David Mazieres To: saag@ietf.org, ilc@ietf.org, trans@ietf.org Date: Thu, 09 Mar 2017 14:07:03 -0800 Message-ID: <87a88uksu0.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Ilc] Talk announcement: Internet-Level Consensus is Practical X-BeenThere: ilc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David Mazieres expires 2017-06-07 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, 09 Mar 2017 22:07:05 -0000 I'll be giving the following 30-minute talk during the saag session at the upcoming IETF meeting in Chicago, likely followed by a "bar bof" on Internet-level consensus that evening. Internet-Level Consensus is Practical David Mazi=C3=A8res Security Area Open Meeting Thursday March 30, 2017 15:20-17:20 Zurich D room =09=09=09=09=20=20=20 Consensus is the problem of agreeing on a valid input value among members of a distributed system. Internet-level consensus extends the concept to global agreement, despite the fact that the Internet has no meaningful notion of membership. This talk will report on the Stellar consensus protocol (SCP), an existence proof that secure consensus does not require well-defined membership. SCP's key idea is for individual participants to decide for themselves which other participants they cannot afford to diverge from. SCP guarantees agreement so long as there is transitive overlap in these dependencies. SCP is in production use by the Stellar payment network, but has broader potential applications ranging from secure package distribution to key management in end-to-end email encryption. From nobody Wed Mar 29 04:43:14 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 F25651296AE; Wed, 29 Mar 2017 04:43:11 -0700 (PDT) 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 LbuxME4BK_04; Wed, 29 Mar 2017 04:43:10 -0700 (PDT) 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 56CA51296AD; Wed, 29 Mar 2017 04:43:09 -0700 (PDT) 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 v2TBh8A2061932; Wed, 29 Mar 2017 04:43:08 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v2TBh8Jb029362; Wed, 29 Mar 2017 04:43:08 -0700 (PDT) From: David Mazieres To: Paul Hoffman , "saag\@ietf.org" Cc: In-Reply-To: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org> References: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org> Reply-To: David Mazieres expires 2017-06-27 PDT Date: Wed, 29 Mar 2017 04:43:08 -0700 Message-ID: <87inmsxq9f.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Ilc] [saag] Distributed ledgers and control X-BeenThere: ilc@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 11:43:12 -0000 Paul Hoffman writes: > Greetings. A few folks have recently been discussing which ledger and > ledger-esque protocols should be used with upcoming IETF protocols. It > is easy to conflate the governance of the ledger with its uses. A good > article that helps make the distinction is: > > https://www.oii.ox.ac.uk/blog/the-blockchain-paradox-why-distributed-ledger-technologies-may-do-little-to-transform-the-economy/ First, a plug for the IETF Internet-level consensus (ILC) mailing list (CCed), which is a good place to discuss these issues: https://www.ietf.org/mailman/listinfo/ilc as well as a reminder of the talk I'll be giving at the Thursday saag meeting: https://www.ietf.org/mail-archive/web/saag/current/msg07651.html The article you forwarded seems like a reaction to the notion that blockchain technologies can somehow supplant or circumvent regulation. That's a common view within the cryptocurrency community, but a highly controversial one outside. Nonetheless, there are different applications for some of the consensus technologies underlying blockchain systems that don't undermine governance and may be of interest to the IETF. In particular, given a mechanism for Internet-level consensus, it becomes possible to execute atomic transactions across parties that don't know or trust one another. Far from undermining regulation, this actually makes it practical to bridge various regulatory jurisdictions (e.g., create a total order across all certificates issued by all CAs, or atomically perform two funds transfers in two different countries). Furthermore, the notion of a blockchain-esque public log can be leveraged for various forms of transparency. For instance, last year there was a controversy in which Apple claimed to refuse an FBI request to sign a special compromised iPhone bootloader. Unfortunately, for all we know, Apple may have signed the software after all while claiming not to for the PR benefit. That they probably didn't yields the worst of both worlds--angering the FBI and still spooking potential customers. Requiring firmware updates to be published in a public log would allow the public to verify whether or not such activity is happening. David From nobody Wed Mar 29 09:05:45 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 090C61294EC for ; Wed, 29 Mar 2017 06:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 PE-yPblS4bD7 for ; Wed, 29 Mar 2017 06:24:59 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 1FC39126DD9 for ; Wed, 29 Mar 2017 06:24:59 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id d191so10313242ywe.2 for ; Wed, 29 Mar 2017 06:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bA4kvGwdVnRevzGyyNsGfvZFnBBBLYIiXJ1ZmzvcBR4=; b=WIt1BL4tEhH0QMb3EOxVgoX7W/t83AZXJHX/4rhwqLim/nbZLcpMSBGxlVgUyURtAI iy3BYTMoy+ih0PykSy9BAsbPgvR9E9AKLLPay77Zc01k3ZuhNY1z0xp6U+n8ddApeQzW qYpPuJwN5z10xZvr1VUshFLab50zClMD3QWSrWI7rtleyyn2KvYi2G1QxLJtNv2YKz72 l/XG2b66EBxfGwH5GD9dsgX+THH4RMgicYf1pZNNMDUHOIa9kTGhtiXArt7cBaYeO3H2 I6sRljEhOt+B7jt6NkaBH+CxsiHVKeBnappnP9QQndMPd4S9PLzetdSvQostvOGntL6l 89qQ== 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=bA4kvGwdVnRevzGyyNsGfvZFnBBBLYIiXJ1ZmzvcBR4=; b=qWMOGEM/nf1ozGQFDLKJeh2qVGgNVp4ARIn9dXwNinBcxbrAcNWRQt1LIrpeZitlLj MNxrjrZa5P6lsxqoxFgFNNTEZnagZuNAaj6GFmETUEfGPLc09syWA93DTPyJW6m4mQ42 T3YhA/Psts/MPl4QhOxeG4fDU0DT0Ta76sz5LITEGObqfvT/iMKkxsEi2YvMRD5Nm5mv MnnkFK+jWKRZb6tsXzzaAFyhnmTJH1DWFk8oyQDxW9X/xbRRx+WEdGd3v/ai8b9NfJz6 uXo/tY13Ffe9/CpMP04fWe7j5d1q52kecqjmSgtwgzPjI+JrAE++0d4GULbU3IBi4wIw 1+yA== X-Gm-Message-State: AFeK/H2JePOItD0MhywBertCivvGpneyM+6+OhjMjEDcX5j1FvZdckKif3TCFM0PZWTTsa1O+amL4duzQ3RnNw== X-Received: by 10.129.177.8 with SMTP id p8mr413311ywh.327.1490793898250; Wed, 29 Mar 2017 06:24:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Wed, 29 Mar 2017 06:24:17 -0700 (PDT) In-Reply-To: <87inmsxq9f.fsf@ta.scs.stanford.edu> References: <7A8F415A-3BE0-46D4-80FF-B8DB50634B94@vpnc.org> <87inmsxq9f.fsf@ta.scs.stanford.edu> From: Eric Rescorla Date: Wed, 29 Mar 2017 08:24:17 -0500 Message-ID: To: David Mazieres expires 2017-06-27 PDT Cc: Paul Hoffman , "saag@ietf.org" , ilc@ietf.org Content-Type: multipart/alternative; boundary=94eb2c13ce38bd2b34054bde8041 Archived-At: X-Mailman-Approved-At: Wed, 29 Mar 2017 09:05:45 -0700 Subject: Re: [Ilc] [saag] Distributed ledgers and control X-BeenThere: ilc@ietf.org X-Mailman-Version: 2.1.22 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, 29 Mar 2017 13:25:02 -0000 --94eb2c13ce38bd2b34054bde8041 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 29, 2017 at 6:43 AM, David Mazieres < dm-list-ietf-ilc@scs.stanford.edu> wrote > > Furthermore, the notion of a blockchain-esque public log can be > leveraged for various forms of transparency. For instance, last year > there was a controversy in which Apple claimed to refuse an FBI request > to sign a special compromised iPhone bootloader. Unfortunately, for all > we know, Apple may have signed the software after all while claiming not > to for the PR benefit. That they probably didn't yields the worst of > both worlds--angering the FBI and still spooking potential customers. > Requiring firmware updates to be published in a public log would allow > the public to verify whether or not such activity is happening. Just for those who may not be tracking this kind of work, this is something that's starting to happen, though typically with semi-centralized consensus mechanisms. In that form, it's generally known as "Binary Transparency". See, for instance: - https://groups.google.com/forum/#!forum/binary-transparency and - https://wiki.mozilla.org/Security/Binary_Transparency -Ekr > David > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --94eb2c13ce38bd2b34054bde8041 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Mar 29, 2017 at 6:43 AM, David Mazieres <dm-list-i= etf-ilc@scs.stanford.edu> wrote
Furthermore, the notion of a blockchain-esque public log can be
leveraged for various forms of transparency.=C2=A0 For instance, last year<= br> there was a controversy in which Apple claimed to refuse an FBI request
to sign a special compromised iPhone bootloader.=C2=A0 Unfortunately, for a= ll
we know, Apple may have signed the software after all while claiming not to for the PR benefit.=C2=A0 That they probably didn't yields the worst= of
both worlds--angering the FBI and still spooking potential customers.
Requiring firmware updates to be published in a public log would allow
the public to verify whether or not such activity is happening.

Just for those who may not be tracking this kind of wo= rk, this is something
that's starting to happen, though typic= ally with semi-centralized consensus
mechanisms. In that form, it= 's generally known as "Binary Transparency".


David

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

--94eb2c13ce38bd2b34054bde8041-- From nobody Thu Mar 30 11:46:45 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 DAC3F129454; Thu, 30 Mar 2017 11:46:43 -0700 (PDT) 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 YrJkw6vzh-OY; Thu, 30 Mar 2017 11:46:42 -0700 (PDT) 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 AA562127843; Thu, 30 Mar 2017 11:46:42 -0700 (PDT) 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 v2UIkgo9075499; Thu, 30 Mar 2017 11:46:42 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v2UIkgjs044018; Thu, 30 Mar 2017 11:46:42 -0700 (PDT) From: David Mazieres To: saag@ietf.org, ilc@ietf.org, trans@ietf.org In-Reply-To: <87a88uksu0.fsf@ta.scs.stanford.edu> References: <87a88uksu0.fsf@ta.scs.stanford.edu> Reply-To: David Mazieres expires 2017-06-28 PDT Date: Thu, 30 Mar 2017 11:46:41 -0700 Message-ID: <8760iqr4a6.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Ilc] Internet-Level Consensus bar BoF tonight 7:30pm, Amuse X-BeenThere: ilc@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 18:46:44 -0000 For those interested in further discussion of Internet-level Consensus (ILC) following my talk at the SAAG open meeting, let's meet at 7:30pm at Amuse, the bar inside Swissotel right near the lobby. David David Mazieres writes: > I'll be giving the following 30-minute talk during the saag session at > the upcoming IETF meeting in Chicago, likely followed by a "bar bof" on > Internet-level consensus that evening. > > > Internet-Level Consensus is Practical > > David Mazi=C3=A8res > > Security Area Open Meeting > Thursday March 30, 2017 15:20-17:20 > Zurich D room >=20=09=09=09=09=20=20=20 > Consensus is the problem of agreeing on a valid input value among > members of a distributed system. Internet-level consensus extends the > concept to global agreement, despite the fact that the Internet has no > meaningful notion of membership. This talk will report on the Stellar > consensus protocol (SCP), an existence proof that secure consensus > does not require well-defined membership. SCP's key idea is for > individual participants to decide for themselves which other > participants they cannot afford to diverge from. SCP guarantees > agreement so long as there is transitive overlap in these > dependencies. SCP is in production use by the Stellar payment > network, but has broader potential applications ranging from secure > package distribution to key management in end-to-end email encryption. From nobody Thu Mar 30 22:20:19 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 6B955128C81; Thu, 30 Mar 2017 22:20:18 -0700 (PDT) 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 H_H0g2R7dfKo; Thu, 30 Mar 2017 22:20:17 -0700 (PDT) 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 115631292D3; Thu, 30 Mar 2017 22:20:17 -0700 (PDT) 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 v2V5KG9f091376; Thu, 30 Mar 2017 22:20:16 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v2V5KGtZ098614; Thu, 30 Mar 2017 22:20:16 -0700 (PDT) From: David Mazieres To: saag@ietf.org, ilc@ietf.org In-Reply-To: <8951becb-fca3-2520-11f1-a05615b49826@gmail.com> References: <87a88uksu0.fsf@ta.scs.stanford.edu> <8760iqr4a6.fsf@ta.scs.stanford.edu> <8951becb-fca3-2520-11f1-a05615b49826@gmail.com> Reply-To: David Mazieres expires 2017-06-28 PDT Date: Thu, 30 Mar 2017 22:20:16 -0700 Message-ID: <87bmsi81kf.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Ilc] ILC bar BoF summary X-BeenThere: ilc@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 05:20:18 -0000 Just a brief follow-up to the bar BoF. We talked about several potential applications of ILC, including enhanced versions of certificate transparency, pseudonymous reputation systems, and software/package transparency. The application that stood out as the most compelling was binary transparency of firmware updates for IoT devices. There's a good chance that powerful actors will attempt to compromise such devices' firmware on a large scale. Merely requiring updates to be digitally signed could prove insufficient if the manufacturer is compromised. By contrast, publicly logging any updates in some data structure checkpointed by all of the world's log authorities would require a far higher level of complicity by the manufacturer and greatly increase the chances of exposing nefarious firmware. We also thought that it might be best to include transparency from the start in any standard for authenticating firmware updates. If we try to add some kind of transparency to an existing firmware update standard, it seems unlikely to get as widespread adoption as if transparency is an integral part of any update standard from day one. David