[Ilc] ILC bar BoF summary

David Mazieres <dm-list-ietf-ilc@scs.stanford.edu> Fri, 31 March 2017 05:20 UTC

Return-Path: <dm-list-ietf-ilc@scs.stanford.edu>
X-Original-To: ilc@ietfa.amsl.com
Delivered-To: ilc@ietfa.amsl.com
Received: from localhost (localhost []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) 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 <dm-list-ietf-ilc@scs.stanford.edu>
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 <mazieres-8gm575uj7umhgcw3qrqy3rukie@temporary-address.scs.stanford.edu>
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: <https://mailarchive.ietf.org/arch/msg/ilc/KTyRRhRNSz6YfQ7DMu4S6KBSoes>
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." <ilc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ilc>, <mailto:ilc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ilc/>
List-Post: <mailto:ilc@ietf.org>
List-Help: <mailto:ilc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ilc>, <mailto:ilc-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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.