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

Greg Rose <ggr@seer-grog.net> Tue, 30 August 2016 05:15 UTC

Return-Path: <ggr@seer-grog.net>
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 9630A12D0F9 for <cfrg@ietfa.amsl.com>; Mon, 29 Aug 2016 22:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seer-grog.net
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 ykv3ZMyDXxIP for <cfrg@ietfa.amsl.com>; Mon, 29 Aug 2016 22:15:06 -0700 (PDT)
Received: from homiemail-a75.g.dreamhost.com (sub3.mail.dreamhost.com [69.163.253.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28ECC12D0C9 for <cfrg@irtf.org>; Mon, 29 Aug 2016 22:15:06 -0700 (PDT)
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id C4AC65EC07F; Mon, 29 Aug 2016 22:15:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=seer-grog.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= seer-grog.net; bh=MfB3NY38M03RLbWndG8/S9Rc4m8=; b=24chl7vrpPfaZa w2ii+U8vQkj46sDL2OumlKLtn6jmao80I7BicCPw68CpTQvRVsdw0jn6osaI9Pus Qn6dCeCwSljct8m5kvG+4td4zM+lA26RY9PL3x4MDL4emFlARxWN+9nrUeIDcuVY H8btZM7zcT1m/OdfWP/gpIxqu6eSA=
Received: from [10.0.1.5] (cpe-76-167-195-197.san.res.rr.com [76.167.195.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ggr@seer-grog.net) by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPSA id 961C55EC079; Mon, 29 Aug 2016 22:15:05 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Greg Rose <ggr@seer-grog.net>
In-Reply-To: <7f01301d-f96f-9b99-7841-e43b5a2d12ea@gmail.com>
Date: Mon, 29 Aug 2016 22:15:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <13E782F9-CAD4-4098-AE6F-3EDE7A0CD3CD@seer-grog.net>
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> <b1956113-b21a-f995-2e35-3011eb76ce8a@gmail.com> <8699AC5D-AD51-4287-A302-55CF9549A7FC@callas.org> <7f01301d-f96f-9b99-7841-e43b5a2d12ea@gmail.com>
To: Rene Struik <rstruik.ext@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/kUI1_-8GJ8M55VGBgY8nVauX_Eo>
Cc: Jon Callas <jon@callas.org>, "cfrg@irtf.org" <cfrg@irtf.org>, Joachim Strömbergson <joachim@secworks.se>, "David McGrew (mcgrew)" <mcgrew@cisco.com>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [Cfrg] (confusing the issues) Re: [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, 30 Aug 2016 05:15:07 -0000

Rene, thanks for clarifying my thoughts on this. You're right, in one sense, piling on on the bandwagon is often counterproductive. I'm reminded of Dijkstra's article "goto statement considered harmful", in 1968, which was cogent and important, but inspired any number of "XXX considered harmful" statements that weren't ... 

But, if you're writing in C (which I think we mostly shouldn't be any more, but that's a different question), there's no practical alternative to using goto! Check this, then check that, then check the other thing... You can't maintain code that has this as one big "if" statement, and you won't get it right if there are 18 layers of nested "if" statements either.

But back to the original question: In my job I had to continually face the objection that "security [any form] was too expensive to implement". My personal breakthrough was understanding the legal concept of "burden of proof". Was it my job to prove that the security wasn't too expensive? Or was it the (non-security) people's job, in the face of the requirement for security (agreed by management), to prove that it WAS too expensive? I could at least argue that measuring the answer was cheaper than either (a) continuing to argue, or (b) implementing it. Guess what the answer was?

I believe that there's a place for 64-bit block ciphers, still. But I believe that there's a corresponding requirement that the analysis be done, and that provision for re-keying must be engineered in, before they can be used. The alternative, just go to 128-bit blocks, is sometimes cheaper, and sometimes easier, and sometimes both. But no handwaving is required... do the analysis!

Greg.

> On Aug 29, 2016, at 18:31 , Rene Struik <rstruik.ext@gmail.com> wrote:
> 
> My argument was aimed at focusing on the real topic at hand, not at mixing this with "religious" beliefs as ditching ciphers without clear justification (no matter how ancient 3-DES may be [I was in elementary school then]).
> 
> I think it is unwise thinking too lightly about writing IETF drafts with "die-die-die" in the title, just because one feels like it, in an almost context-free manner. Or, is the idea to launch an entire series of die-die-die drafts, because one finds some excuse to do so? I cannot deny I also like shiny new things and we may all suffer from not-invented-here syndromes, but acknowledging this playing in the background of our perceptions should also give us some reason to pause and have some restraint here.
> 
> Rene
> 
> On 8/29/2016 5:48 PM, Jon Callas wrote:
>>> On Aug 29, 2016, at 6:26 AM, Rene Struik <rstruik.ext@gmail.com> wrote:
>>> 
>>> 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).
>> Yes, we should just stop using 64-bit block ciphers and deal with the issues you mention within the context of larger blocks.
>> 
>> 	Jon
>> 
> 
> 
> -- 
> email: rstruik.ext@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg


Phone:  +1 619 890 8236 
GPG/PGP:  1081A37C  232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C