Re: [TLS] [Cfrg] 3DES diediedie

"David McGrew (mcgrew)" <mcgrew@cisco.com> Mon, 29 August 2016 12:44 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05CC12D539 for <tls@ietfa.amsl.com>; Mon, 29 Aug 2016 05:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.069
X-Spam-Level:
X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RE0DNZWos3H for <tls@ietfa.amsl.com>; Mon, 29 Aug 2016 05:44:44 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805E012D555 for <tls@ietf.org>; Mon, 29 Aug 2016 05:44:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3720; q=dns/txt; s=iport; t=1472474684; x=1473684284; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=wc/z0nTzceVj3ErQgg98EPtfwKLv8eeI5T15A+1bUz0=; b=c4+9Evy5tdDH9G4bMGswsBiBOdiJ/h19WlLWKUmy/t0VfC7FS1y3l9WI l2YOx1GH19zBuodPAAuTWDaunrBi+wFpcH5+H0lOqdCelu+XdVVJMcGXI y0BrglcOy/+uGcs7Fmz2ORO77Rej/k6PdMcuHzBOHFHOhDKsXH3w8AV0P Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DOAQA6LcRX/5pdJa1cDgwBAQEBAgEBAQGDKQEBAQEBHld8B40nqneCASaFdwIcgSc4FAECAQEBAQEBAV4nhGIBAQICIxFVAgEIDgwCJgICAjAVEAIEARKIQA6uCo8vAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQOHI4JVghCCEwEBgx0rgi8FhhKTPQGGH4I9gz6DEII7jRqQPAEeNoI0HIERO3ABhCyBIH8BAQE
X-IronPort-AV: E=Sophos;i="5.28,596,1464652800"; d="scan'208";a="140705387"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2016 12:44:43 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u7TCihAB021445 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Aug 2016 12:44:43 GMT
Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 29 Aug 2016 07:44:42 -0500
Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1210.000; Mon, 29 Aug 2016 07:44:42 -0500
From: "David McGrew (mcgrew)" <mcgrew@cisco.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Tony Arcieri <bascule@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] 3DES diediedie
Thread-Index: AQHR/nWfoW+SS6smqUOyCtdxrLUgKaBbmdgAgAF4CoD//8XhAIABxwsAgAFbRAA=
Date: Mon, 29 Aug 2016 12:44:42 +0000
Message-ID: <3401C8F7-5A74-4D02-96F5-057E9A45F8B0@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>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D0528F@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.10.228]
Content-Type: text/plain; charset="utf-8"
Content-ID: <522EA66CF2E28E43A944C93BD1A91FF5@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/gfvjLawwnwdi9FC-Xk8dZk2Yrd8>
Subject: Re: [TLS] [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 12:44:48 -0000

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.