[TLS] (confusing the issues) Re: [Cfrg] 3DES diediedie

Rene Struik <rstruik.ext@gmail.com> Mon, 29 August 2016 13:26 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E46EF12D5EC for <tls@ietfa.amsl.com>; Mon, 29 Aug 2016 06:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id J26bA2svNdI2 for <tls@ietfa.amsl.com>; Mon, 29 Aug 2016 06:26:38 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B60712D619 for <tls@ietf.org>; Mon, 29 Aug 2016 06:26:35 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id t7so137173262qkh.1 for <tls@ietf.org>; Mon, 29 Aug 2016 06:26:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=oSbXFj9Wy3vRGhlwz0fa0s+4xLeLxGwN1RcbliviTY8=; b=HQHSaDNq2R9VyplPnqk15ZdkfZ+I5EEaKMJANmtNDHGK+9vYVDkp4L97mut9XX7L+n UTef5NirGI3ydadCFHvzx24Lw3GR1moti68M/jOC4Ce1HRmEa07FrRLYv4wtgp0AXGii OYRZENYxmfssHTIFsZjSGv3TYyZ4wo2QyX6hmOvbJ/5MptCc2c8X22v2Rl2nQ6cVOGUv iE0T/+YEVqwxiOdqw05XeaCDdyeT7SJSMFMTuwboYXiBFVgLNCNK2qectg+AlFN9EcLF tMnCBHUb+Dl3aUr5z89pINZ+5iv+xV+3aSrzYpGx133CvkCUQH5BJf4mdwdHlzwUO8UL usfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=oSbXFj9Wy3vRGhlwz0fa0s+4xLeLxGwN1RcbliviTY8=; b=ltOgUtSkxATaYw14Cc2d12IgXCyKWIHahQ21qEDhpWJlMPlFBVXr7ruArstS89/cle 0nFQz/dj/mjylsHp7ly8vBrBxE+4K/MXvjegFeYP9ipN8FMPNz1w2LKj1xaQ9aHYDhDg ZMVlFUGRpptFO2VWnBh4loV2jCoGRc5xkRCUHnCjlrdjrAaBVM7TRlZPiI/deGWSG+YC JNRlAaQMrOik9ABkfaZz6bs9As2NV7rzmPAhdPqrZjoOvHsBY3PNayPFhWQ1dJmRxOYJ lVPjdlzA+eNlpaauNqboUEm4MF/CzTZR2lmL+lRF2iwxMzkeHV99j0RzFqWwcxlpwvAF YzMA==
X-Gm-Message-State: AE9vXwMMyC+9ck2R4DL9K/OlstSO57eD/hHRgXXFbEU//KIKmqz2SltKp5aqmNAuvnARlg==
X-Received: by with SMTP id w10mr18790946qkw.43.1472477194219; Mon, 29 Aug 2016 06:26:34 -0700 (PDT)
Received: from [] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. []) by smtp.gmail.com with ESMTPSA id c26sm18598415qte.1.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 06:26:33 -0700 (PDT)
To: =?UTF-8?Q?Joachim_Str=c3=b6mbergson?= <joachim@secworks.se>, "David McGrew (mcgrew)" <mcgrew@cisco.com>
References: <CAHOTMV+r5PVxqnSozYyqJqq_YocMKV06aAa-43t+5Huzh7Lo=A@mail.gmail.com> <F42128A0-9682-4042-8C7E-E3686743B314@cisco.com> <9A043F3CF02CD34C8E74AC1594475C73F4D0473F@uxcn10-5.UoA.auckland.ac.nz> <B749662D-B518-46E0-A51D-4AD1D30A8ED2@cisco.com> <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz> <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@cisco.com> <57C43102.7090902@secworks.se>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <b1956113-b21a-f995-2e35-3011eb76ce8a@gmail.com>
Date: Mon, 29 Aug 2016 09:26:18 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <57C43102.7090902@secworks.se>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1Mvx-PUVz3NzeLYMnej0kFEh33g>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, "<tls@ietf.org>" <tls@ietf.org>
Subject: [TLS] (confusing the issues) Re: [Cfrg] 3DES diediedie
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Aug 2016 13:26:41 -0000

I think it is a mistake to think that simply using block ciphers with a 
larger block size is enough to counter attacks, as the literature on 
successful side channel attacks on such block cipher demonstrates. The 
real message is that one should not reuse keys ad infinitum, which 
unfortunately seems hard to sink in.

Singling out 3-DES in this respect does not seem to tackle the real 
issue (which is a system security issue often only paid lip service to 
in practice).


On 8/29/2016 8:56 AM, Joachim Strömbergson wrote:
> Hash: SHA256
> Aloha!
> 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.
> https://www.cryptolux.org/images/a/a0/Beaulieu-DAC2015.pdf
> https://eprint.iacr.org/2015/209.pdf
> Yours
> JoachimS
> 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:
>> http://csrc.nist.gov/groups/ST/lwc-workshop2015/presentations/session4-shumow.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.
>> David
>> On 8/28/16, 8:01 AM, "Peter Gutmann" <pgut001@cs.auckland.ac.nz>
>> wrote:
>>> David McGrew (mcgrew) <mcgrew@cisco.com> 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
>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> - -- 
> Med vänlig hälsning, Yours
> Joachim Strömbergson - Alltid i harmonisk svängning.
> ========================================================================
>   Joachim Strömbergson          Secworks AB          joachim@secworks.se
> ========================================================================
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> HViof7jYA7yvbZm9SeYkV88y4sOMUQrhSsAWUZ7GfwcjkjC8+sL8mD7uacPx0zpW
> rAnLnAHJbnU8rkWRT2OKWiZBvwMpMNw/UYGy13dwilRExj22N4dsLK98vath3r52
> FjAIL2GpCWUuzPB6P5d+B8MjEwEr1tEYzvlvWo032RB91irOOKveryGGe5ifnSKj
> SP1a9CbakaLdTHMkrhOre0I4Ckr2A97eI3oo/5QjRJ81zKJ/4VZzOOe3lGjPkXhO
> kzkANctte+Eb5ttlaXcg/dL7lStzaYo8rnm3PRHsBKpHr/oNEgbdJti1U78/MfLf
> o0v+s4TbY7YBPXOU7zKWpo9VD1Mcq9eMAslIQokEE2CfIq3wBSEEgKwJXu6HVSht
> Ohahc7HUBnz2+uXJ+x4hl/bW/qM3DFhTfhPCYQ11IiXpPlxhsAnxbszBe4XtHd7y
> z2Uc+Jef8aUq7sEGYBdcnGs+SSNFQwtUIicKI3pU61xvtAhqRriNOsfmCVvC2V7Z
> iz5EodInPjUBkVMwDbmiFd5lp782SqYZsivwabPGE1p2GG+o421KZmQJ3VRC3ctw
> xjwk2HszIv7Wo+gomL0hqF7Wi0YIP556rRYrRMc9gLV513xzxD5T99eR+2HtiRJF
> TvYYPXZjzP087liGF7SA
> =Z0iM
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363