Subject: [Ilc] Welcome to the ILC list

From: [email-masked]
Date: Mon, 13 Feb 2017 12:24:26 -0800

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: Kyle Rose <[email-masked]>
Date: Thu, 16 Feb 2017 13:23:17 -0500

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, <[email-masked]> wrote:

> _______________________________________________
> Ilc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ilc
>

---

From: Tom Ritter <[email-masked]>
Date: Thu, 16 Feb 2017 12:44:12 -0600

> 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: Tao Effect <[email-masked]>
Date: Thu, 16 Feb 2017 12:14:29 -0800

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 <http://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—as this group and [trans] are proposing—consolidates 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—but 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 <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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> [email-masked] <mailto:[email-masked]>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Feb 2017 14:58:14 +0100

On Thu, Feb 16, 2017 at 12:14:29PM -0800,
 Tao Effect <[email-masked]> 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.

---

From: Tao Effect <[email-masked]>
Date: Fri, 17 Feb 2017 12:43:44 -0800

> 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 <http://apple.com/> [2].

[1] https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md#dnssec <https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md#dnssec>
[2] https://www.ssllabs.com/ssltest/analyze.html?d=apple.com&s=17.178.96.59&latest <https://www.ssllabs.com/ssltest/analyze.html?d=apple.com&s=17.178.96.59&latest>

- Greg

> On Feb 17, 2017, at 5:58 AM, Stephane Bortzmeyer <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Tao Effect <[email-masked] <mailto:[email-masked]>> wrote
>> network connection, can override apple.com <http://apple.com/> <http://apple.com/ <http://apple.com/>>
>