Re: [Cfrg] [TLS] 3DES diediedie

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 06 September 2016 21:23 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8B212B1DB for <cfrg@ietfa.amsl.com>; Tue, 6 Sep 2016 14:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.809
X-Spam-Level:
X-Spam-Status: No, score=-5.809 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_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 O7vioyL2CzKX for <cfrg@ietfa.amsl.com>; Tue, 6 Sep 2016 14:23:21 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484F212B0D8 for <cfrg@irtf.org>; Tue, 6 Sep 2016 14:23:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4117ABE50; Tue, 6 Sep 2016 22:23:19 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMry-RrZQ3ei; Tue, 6 Sep 2016 22:23:17 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 696C0BE4D; Tue, 6 Sep 2016 22:23:17 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1473196997; bh=dlxhlTPNU4jNcwjz/ph8vPFmGTkUlHKB+Kcnwd4QbIQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=HyQLoO7Bpfe4zF/ioXnMux0myrZgD3MT0siiZBVKSYP2plf7wYMX1smxfveRBoW2M 33PR3Qd8HZgWnyMpR1RXh1QMPyncuYWhtSy4+Z0f1mfvAXgOtUWRlrNsB+cACBY1kq 7n1mshRHAUKVwB8YPaiF9P8acGI7H+WsovCULCgw=
To: Derek Atkins <derek@ihtfp.com>, Joachim Strömbergson <joachim@secworks.se>
References: <20160906114030.18292816.41703.89024@ll.mit.edu> <57CEAE6F.1040608@secworks.se> <sjmeg4wvjut.fsf@securerf.ihtfp.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <d1b84ec2-5b02-b285-8304-e3b393d9ee4a@cs.tcd.ie>
Date: Tue, 06 Sep 2016 22:23:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <sjmeg4wvjut.fsf@securerf.ihtfp.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms050409080303040403040909"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/FAQyWaO3VrTk75sXXoNAG6297sY>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Hilarie Orman <hilarie@purplestreak.com>
Subject: Re: [Cfrg] [TLS] 3DES diediedie
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2016 21:23:24 -0000

Hi Derek,

On 06/09/16 21:44, Derek Atkins wrote:
> I'm afraid I have to disagree here.  What's it's done is pushed
> yesterday's computation capabilities into smaller and smaller devices,
> lower and lower on the food chain.  C.f. my previous email about a light
> bulb.  Cost is definitely a concern, as well as power and performance.

I think that's true but not the entire story.

Another part of the trade off is that any device that
connects to the Internet and runs s/w is potentially
vulnerable and usable to attack the network.

So we're not only talking about security/crypto to
protect someone's choice of what colour a bulb appears,
but rather we're very often talking about the protection
of a small computer on the network, and of the security
of the network as a whole.

That last I think argues strongly for support for
sufficiently good crypto everywhere. And I'm not sure
what sufficiently good options exist that are notably
lighter weight than AES. (And if one does support good
crypto then there seems less reason to use less good
crypto for some functions.)

Note that I'm arguing against weaker crypto or crypto
of unknown or possibly-problematic provenance here. So
I'm not arguing for HW-AES-everywhere. But it is also
true that AES-everywhere would avoid this significant
problem.

That said, I do realise that this is not a winning
argument as people will develop feature-rich devices
with crap security and there's no device-police to stop
them, but we (as in cfrg) should really also bear in
mind that any weaker crypto anywhere has significant
downsides as many devices really do need what we currently
consider strong crypto because they connect to the
Internet and may not get any updated s/w for quite some
time.

So... it's tricky - I think we know what's right but we
also know that that's not what "the market" is going
to produce;-)

S.