Re: [TLS] [Cfrg] 3DES diediedie

John Mattsson <> Mon, 29 August 2016 13:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6EE812B028 for <>; Mon, 29 Aug 2016 06:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RlowTCPe9GwZ for <>; Mon, 29 Aug 2016 06:20:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AA5212D112 for <>; Mon, 29 Aug 2016 06:20:55 -0700 (PDT)
X-AuditID: c1b4fb30-ea88e980000009f9-af-57c436b52fd8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DA.95.02553.5B634C75; Mon, 29 Aug 2016 15:20:53 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Mon, 29 Aug 2016 15:20:49 +0200
From: John Mattsson <>
To: "David McGrew (mcgrew)" <>, Peter Gutmann <>, Tony Arcieri <>, "<>" <>, "" <>
Thread-Topic: [Cfrg] 3DES diediedie
Thread-Index: AQHR/8MHpyiCNxbgBkyiSa8rLoEeV6Bcme6AgAAI8ACAAYP9AIABnlEAgAArnoA=
Date: Mon, 29 Aug 2016 13:20:49 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7me5WsyPhBvd2aFlcetzCZNH94yCT xdVVf9gtXr57zmrx6XwXowOrx5TfG1k9LjYeYPLYOesuu8eSJT+ZPCZvPMwWwBrFZZOSmpNZ llqkb5fAlfH9cSNTwR7tiodbUhoY12h1MXJySAiYSLzd+Yepi5GLQ0hgPaPEsRkzmUASQgJL GCXu7OAEsdkEDCTm7mlgAykSETjIKPFs+VI2kISwgJLE4eZm5i5GDqCEssS01/EgYREBP4lp 6zvYQWwWAVWJyV0rmUFsXgFzie2Pp7BALPvNJPG6aRIjSIJTwFbi/8eFLCA2o4CYxPdTa8CO YBYQl7j1ZD4TxKUCEkv2nGeGsEUlXj7+xwpiiwroSTw7uZgRIq4osfNsO9g9zAKaEut36UOM sZa4fHIxG4StKDGl+yE7xD2CEidnPmGZwCg2C8m2WQjds5B0z0LSPQtJ9wJG1lWMosWpxUm5 6UZGeqlFmcnFxfl5enmpJZsYgfF4cMtvgx2ML587HmIU4GBU4uFNeHcoXIg1say4MvcQowQH s5II7xvTI+FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUa GI2L2rcvu9SxRvPciT0zUwIeZ7W2JuzP4NL4Wb+Rff7+TcmL7p76uPLFIUaRdVd239X/XHDq SOf0kD8y/39xnp6w/MNuIZFe2z4GO9ad2k5tkvtDFlpLCv/1lM6J9TC21Lx4Y6bXstl/D0ks f5HSzeEj+pE3c66U5s3jdlPyvv97uervrSSf3v9KLMUZiYZazEXFiQBEUGtcwwIAAA==
Archived-At: <>
Subject: Re: [TLS] [Cfrg] 3DES diediedie
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Aug 2016 13:21:00 -0000

Hi David and Peter,

I think Daniels presentation is a good summary and I tend to agree with
the “No lightweight cryptography in software”. But how relevant is
lightweight cryptography in IoT hardware? I been hearing some hardware
people stating that the number of gates is more and more irrelevant and
that the additional cost of 1000 GE is negligible with current
manufacturing techniques (i.e. 1000 GE is small compared to the are needed
to cut out the circuit and connecting it). We already know that the energy
cost of symmetric  crypto is negligible compared to wireless communication
(this might however change with passive radio).

Would be interesting to hear more input on the relevance of AES- and
SHA-replacements in IoT hardware. Depending on the outcome the CFRG way
forward should be either:

 - Recommendation how to use block ciphers with 64 bit block size
 - Recommendation not to use block ciphers with 64 bit block size


On 29/08/16 14:44, "Cfrg on behalf of David McGrew (mcgrew)"
< on behalf of> wrote:

>Hi Peter,
>You make a bunch of good points.   But it is also worth noting that some
>people feel that current crypto standards, including IETF standards, are
>suitable for IoT.   See for instance slides 8 and 9 of Daniel Shumow's
>talk at NIST’s LWC workshop last year:
>mow.pdf   Also, CoAP isn’t on his list, but it could be, and it uses
>DTLS.   So while I agree with you that overuse of a 64-bit block cipher
>is far from the biggest security concern for IoT, the IETF should expect
>its protocols to be used in some IoT scenarios.
>The malleability of the term IoT is causing trouble here.   Slide 6 of
>Daniel’s talk is quite revealing.  To my thinking, by definition IoT
>devices are connected to the Internet in some way.
>On 8/28/16, 8:01 AM, "Peter Gutmann" <> wrote:
>>David McGrew (mcgrew) <> writes:
>>>I don’t think you understood my point. IoT is about small devices
>>>to the Internet, and IETF standards should expect designed-for-IoT
>>>crypto to
>>>be increasingly in scope.  It is important to not forget about these
>>>amidst the current attention being paid to misuses of 64-bit block
>>>which was the ultimate cause of this mail thread.
>>But the IETF has a long history of creating standards that completely
>>IoT.  I can't think of a single general-purpose IETF security standard
>>SSH, IPsec, etc) that has any hope of working with IoT devices (say a
>>ARM-core ASIC with 32kB RAM and 64kB flash).  This is why the ITU/IEC
>>and a
>>million lesser-known standards bodies are all busy inventing their own
>>exquisitely homebrew crypto protocols, most of which make WEP look like a
>>model of good design.
>>(I've always wanted to sit down and design a generic "encrypted pipe
>>from A to
>>B using minimal resources" spec, and I'm sure many other people have had
>>same thought at one time or another).
>>So it seems like you've got:
>>- The "TLS = the web" crowd (browser vendors and the like) who will
>>  whatever's trendy at the moment and assume everyone has a quad-core
>>2GHz CPU
>>  with gigabytes of RAM and access to weekly live updates and hotfixes.
>>- Embedded/SCADA folks who need to deal with 10-15 year product cycles
>>(see my
>>  TLS-LTS draft for more on this) and are kind of stuck.
>>- IoT people, who can't use any standard protocol and will get the least
>>  unqualified person on staff to invent something that seems OK to them.
>>I'm not sure that a draft on theoretical weaknesses in 64-bit block
>>ciphers is
>>going to affect any of those...
>Cfrg mailing list