From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Nico Williams <nico@cryptonector.com>, Dave Garrett
 <davemgarrett@gmail.com>
Thread-Topic: [TLS] Consensus Call on MTI Algorithms
Thread-Index: AQHQbKeDwNeK1AEgwEC7Z+eGtfd7J5032jcAgAAvggCAAAfCAIAAsbcAgAAQGYCAATtLPv//MgCAgAAG/QCAAAfngIAABgwAgAGuO8k=
Date: Fri, 3 Apr 2015 09:14:21 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFD49FE@uxcn10-tdc05.UoA.auckland.ac.nz>
References: <CAOgPGoBk+E=cNV1ufBaQ0n7=CJQ34zukPixKCEdpmMLBX=Kg_w@mail.gmail.com>
 <FDDE70B3-6AB0-4702-A713-70B118CA22C1@gmail.com>
 <20150402194417.GJ10960@localhost>
 <201504021612.35877.davemgarrett@gmail.com>, <20150402203412.GK10960@localhost>
In-Reply-To: <20150402203412.GK10960@localhost>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/QOyAP9sxBqnPXf5GgmO3FAJqQp4>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Consensus Call on MTI Algorithms
Precedence: list

Nico Williams <nico@cryptonector.com> writes:=0A=
=0A=
>Sure, that'd be nice (because different manufacturers of IoT devices will=
=0A=
>want to know what to implement as a common denominator).=0A=
=0A=
The IoT environment doesn't work the way some people seem to think it does.=
=0A=
IoT devices can be divided into two classes, those that can't run TLS and=
=0A=
those that can.  The class "those that can't run TLS" is a lot larger than =
you=0A=
think, because a typical target might for example have 15% of an ARM7 TDMI =
and=0A=
18K RAM available, and restrictions like the fact that no operation can tie=
 up=0A=
the CPU for more than 2ms before it's killed by the system watchdog.=0A=
=0A=
So for "TLS" on these devices you've got a large class of systems that have=
 to=0A=
run some homebrew protocol invented by an embedded systems guy who's read t=
he=0A=
first three chapters of Applied Cryptography (this became particularly=0A=
problematic when smart meters started to become widespread and regulators=
=0A=
imposed requirements for certificate-based signed messaging and updates ont=
o=0A=
CPUs like TI MSP430s, Motorola ColdFires, and ARM Cortex-Ms, some clocked a=
s=0A=
high as 16MHz and with as much as 32kB of RAM (for everything, not just the=
=0A=
crypto).  The solution with smart meters was to cut corners as much as=0A=
possible in order to make things fit, skipping certificate verification,=0A=
assuming hardcoded public keys, and various other measures that are destine=
d=0A=
to become entertaining Black Hat or Defcon presentations in the future).=0A=
=0A=
For the other class, those that can run TLS, the reason for running it isn'=
t=0A=
to talk to another device running TLS (you use your homebrew protocol for=
=0A=
that), it's so they can be controlled via a web interface.  For these devic=
es=0A=
the profile is "whatever we need to implement to talk to a web browser/smar=
t=0A=
phone/web control/AJAX/whatever".  That is the entire device profile.  Sinc=
e=0A=
the underlying hardware can't handle this, you get approaches like the ones=
=0A=
I've talked about in the past, 1024-bit keys for everything (perfectly OK f=
or=0A=
embedded device security, I've been waiting for the negotiated-ff-dhe draft=
 to=0A=
be approved so I can push out one that extends it to specify 1024- and 1280=
-=0A=
bit parameter sets), pre-encoded cert chains memcpy()'d out into TLS stream=
s=0A=
(the device has zero PKI functionality because there isn't room), and so on=
,=0A=
just whatever you can get away with and have the other side still talk to y=
ou=0A=
(I've seen some truly ingenious solutions applied to systems that have to t=
alk=0A=
to web browsers but just can't handle the high resource requirements for TL=
S).=0A=
=0A=
If you want to do an IoT TLS profile (what would have been called an embedd=
ed=0A=
device TLS profile before IoT became a buzzword) you need to look at how TL=
S=0A=
is used in the embedded world, and for what purposes.  Simply dreaming up=
=0A=
something and calling it an IoT profile won't work, because vendors are=0A=
already working with de facto profiles of "whatever we need to do to get=0A=
things working".=0A=
=0A=
Peter.=