Re: [TLS] [Cfrg] 3DES diediedie

Joachim Strömbergson <> Mon, 29 August 2016 12:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23F4012D58A for <>; Mon, 29 Aug 2016 05:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lkCyyudweIO0 for <>; Mon, 29 Aug 2016 05:56:40 -0700 (PDT)
Received: from ( [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A97F12D0FE for <>; Mon, 29 Aug 2016 05:56:40 -0700 (PDT)
Received: from Knubbis.local (unknown []) by (Postfix) with ESMTPSA id DA4E421EEE; Mon, 29 Aug 2016 14:56:37 +0200 (CEST)
Message-ID: <>
Date: Mon, 29 Aug 2016 14:56:34 +0200
From: =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= <>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: "David McGrew (mcgrew)" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: "" <>, "<>" <>
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 12:56:43 -0000

Hash: SHA256


As a side note, there has been a bunch of lightweight block ciphers
suggested the last few years, most of them with a block size of 64 bits.
And there has been discussion on IETF maillists about IETF accepting
them. For example the SIMON and SPECK ciphers. These ciphers can have
block sizes as small as 32 bits.


David McGrew (mcgrew) 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:
> 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.
> David
> 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
>>> connecting 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 devices, amidst the current
>>> attention being paid to misuses of 64-bit block ciphers, which
>>> was the ultimate cause of this mail thread.
>> But the IETF has a long history of creating standards that
>> completely ignore IoT.  I can't think of a single general-purpose
>> IETF security standard (TLS, SSH, IPsec, etc) that has any hope of
>> working with IoT devices (say a 40Mhz 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 the 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
>> implement 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...
>> Peter.
> _______________________________________________ TLS mailing list 

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
 Joachim Strömbergson          Secworks AB
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -