Re: [Ilc] New Non-WG Mailing List: Ilc -- Discussion of mechanisms and applications for Internet-level consensus.

David Mazieres <dm-list-ietf-ilc@scs.stanford.edu> Mon, 13 February 2017 01:04 UTC

Return-Path: <dm-list-ietf-ilc@scs.stanford.edu>
X-Original-To: ilc@ietfa.amsl.com
Delivered-To: ilc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4091294AA for <ilc@ietfa.amsl.com>; 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 <ilc@ietfa.amsl.com>; 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 <ilc@ietf.org>; 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 <dm-list-ietf-ilc@scs.stanford.edu>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>, 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: <https://mailarchive.ietf.org/arch/msg/ilc/bcNWZ2_ZfNYeCpGB6pSVFLdDI-Q>
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 <mazieres-kbx5a5dzrbyhb24s2xzbw2t296@temporary-address.scs.stanford.edu>
List-Id: "Discussion of mechanisms and applications for Internet-level consensus." <ilc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ilc>, <mailto:ilc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ilc/>
List-Post: <mailto:ilc@ietf.org>
List-Help: <mailto:ilc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ilc>, <mailto:ilc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2017 01:04:31 -0000

Stephane Bortzmeyer <bortzmeyer@nic.fr> writes:

> On Fri, Feb 10, 2017 at 11:39:45AM -0800,
>  IETF Secretariat <ietf-secretariat@ietf.org> 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
> <https://www.stellar.org/developers/guides/concepts/federation.html>?

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