Re: Observations on (non-technical) changes affecting IETF operations

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 07 March 2016 19:17 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfc.amsl.com
Delivered-To: ietf@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C99191CD99E for <ietf@ietfc.amsl.com>; Mon, 7 Mar 2016 11:17:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.45
X-Spam-Level:
X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, 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: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8K6e2CPxpAG for <ietf@ietfc.amsl.com>; Mon, 7 Mar 2016 11:17:18 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 159B91CD99D for <ietf@ietf.org>; Mon, 7 Mar 2016 11:17:18 -0800 (PST)
Received: by mail-lb0-x22b.google.com with SMTP id bc4so142324116lbc.2 for <ietf@ietf.org>; Mon, 07 Mar 2016 11:17:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=3khUXmRGYm+PL1TL0RjoYouEfrYVgeuHeG4+ojTvc40=; b=jT6LsDUlO4AqQefCVyzEPaW9ZtO+cdou6LTMU41/IaHBzt8C8z2+MZexOa4NiQyjEp PaylmxhsGgnoJu8ysD4+04zOkLB6BTbKNKjAohlXiR1qLf6a+CILmG78DniHJCSMYNBJ pY6qXBfr0nFSs49E/YkZTbUcDPmt57jRXdY9tf2pJUpmnnyruTprLk2O5BmaE50ux1lq qzBmeEloRlZb0bjc74Jbv7DTMoOq5enbdHVSTV4lv+IHGRYEMxpT9xuBaPYmreOncbbP JgTvW2PBx4Vj8fOI9EUMGFGmMEJt6jTUwQe4JC54mBAsxRJ6x2HHA3oUILbfLurn2Es9 NajA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3khUXmRGYm+PL1TL0RjoYouEfrYVgeuHeG4+ojTvc40=; b=aCs2s7lYB7eVBH1lPLzt7iZKe4eXEp1V0+fERjKEAdGeCBzvg5/CQBbVkU9KDVL+z7 B67JaM3itqYtxwty5KTkvUoktNOoqiz9TyQrfdFeuaUt+n4mZkCyXFX2T8o1MjOclcEd mNK45jymhmiERUeCcbJAY1LT1WzJromq5px1f+9Dt8QAmk8V0PJLZQoXcRWoYkBwyLRb /vOYZ+1zzbCsRjNA2qFC9jcpAeT2/b5tLIEpSdD5kT3xq2aCx34I64KlQEjk1mxKy+ma xBWxZG6cKaS4kkRjt/cQEzcwlTA+2vpaWEkGig5TIrj1y+OT0HZ1703778w5eVEnwppo k6rw==
X-Gm-Message-State: AD7BkJLoK1idUO7MgBVwrUS1eVkoLUZcI2BOdJ/LpF8EJZAVKGSrxM50GZ3jfAgWhtev0tJ3xSnwg3BkpDs3nw==
MIME-Version: 1.0
X-Received: by 10.25.165.4 with SMTP id o4mr6544091lfe.43.1457378236052; Mon, 07 Mar 2016 11:17:16 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.151.67 with HTTP; Mon, 7 Mar 2016 11:17:15 -0800 (PST)
In-Reply-To: <56DD876C.6050008@cs.tcd.ie>
References: <E83FC2B4-867D-44C9-AE1B-F4C414ABD041@piuha.net> <4A95BA014132FF49AE685FAB4B9F17F657DF2330@dfweml701-chm> <EDFB7D0B-2A49-46BD-A84C-0E1FA07793FA@piuha.net> <20160307133944.GB25576@gsp.org> <56DD876C.6050008@cs.tcd.ie>
Date: Mon, 7 Mar 2016 14:17:15 -0500
X-Google-Sender-Auth: Nsf7FVixcXbzjEa8XMTwUHqCxH8
Message-ID: <CAMm+LwiBT9S-twGVzC-7yVBZ9dHA3+8f4ffPv3LyoZ_8+kdqmw@mail.gmail.com>
Subject: Re: Observations on (non-technical) changes affecting IETF operations
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/QfsE_bhIa3mggn6marYSAHFSvkk>
Cc: Rich Kulawiec <rsk@gsp.org>, IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Mar 2016 19:17:20 -0000

First, I disagree with Jari's original analysis of the problem. The
Internet security problem is not limited to IoT:

* The use of TLS in most protocols is subject to downgrade attack

* DNSSEC zones are being signed but virtually no-one is changing
behavior based on signature verification results.

* Only 0.1% of email users have enabled an end-to-end security
solution and most of those use it less than 1% of the time.

* We still use passwords as these are the only ubiquitous
authentication mechanism that is compatible with every protocol.

* The set of secure SMTP authentication mechanisms that are supported
by every widely used email client is the null set, as is the
intersection between the set of secure authentication mechanisms
supported by the default clients on many widely used platforms and
many of the major mail services.

* It takes an expert user over 15 minutes to configure Thunderbird to
use an S/MIME certificate. To configure OpenPGP it is necessary to
download a plugin.

And I could go on and on and on.

So what is different about IoT?


I think the big difference is that in IoT it is impossible to ignore
the usability problem that cripples most IETF security protocols. With
the new EC curves we can now do public key crypto on 16 bit and even 8
bit devices (just don't do it too often). But we are still constrained
by the affordances of the devices:

* IoT devices don't always have display capability

* IoT devices often don't have a keyboard device.


Once we recognize the fact that our principal constraints are
usability constraints, we can develop an architecture that addresses
the problems of the IoT world and also the Internet in general.

We are not going to be able to configure cryptography or any other
settings on an IoT device. But we have a variety of protocols that can
be used to connect an IoT device to a 'secure console' where
administration takes place:

* Device has an LED status light and a QR Code with the SHA-2 digest
of a public key printed thereon. Administrator connects device through
a mobile app that uses the camera.

* Device has an SD Card with a site specific O/S build that includes
the 'connection authentication key' of the site. This is then used
together with the MAC address to bootstrap a connection.

Now I am not going to go through the math or the protocol here, but
those of you with crypto knowledge will know how to solve those use
cases. Configuring wireless is harder than wired of course as you have
to configure the WiFi settings. But that could be sorted with a change
to the WiFi specs to add a standardized 'calling channel' SSID.


This is the set of problems I think I have solved with the
Mathematical Mesh. If you go to my Web site http://prismproof.org/ you
will see a demonstration of the Mesh in action. First a Mesh profile
is created on one machine.  The profile manager automatically adds in
S/MIME configuration data to the email account on the first machine
(will be OpenPGP as well in the future).

Then a second machine is connected to the profile. This is initially a
completely blank machine with no email account settings at all. When
the machine is connected to the Mesh profile (using mutual
authentication, naturally), all the email account settings are copied
into the second machine.

The problem of connecting up a lightswitch or a light is essentially
the same. I am using the same exact approach to connect up components
within my robots. My plans to motorize my dalek prop involve three
separate controller boards, one for the base, another for the
shoulders with the gun and manipulator arm, a third for the eyestalk
and lights on the dome. The controller boards all exchange secure
messages with a controller hub.


http://prismproof.org/