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

Jon Callas <jon@callas.org> Mon, 29 August 2016 21:48 UTC

Return-Path: <jon@callas.org>
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 A699312D89C for <tls@ietfa.amsl.com>; Mon, 29 Aug 2016 14:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 oCMWVll9OfVw for <tls@ietfa.amsl.com>; Mon, 29 Aug 2016 14:48:42 -0700 (PDT)
Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id D5D74126FDC for <tls@ietf.org>; Mon, 29 Aug 2016 14:48:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id AB856A14A76F; Mon, 29 Aug 2016 14:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at merrymeet.com
Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB5ytJ+pqddC; Mon, 29 Aug 2016 14:48:42 -0700 (PDT)
Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 75ACCA14A762; Mon, 29 Aug 2016 14:48:42 -0700 (PDT)
Received: from [10.119.8.127] ([173.245.83.244]) by keys.merrymeet.com (PGP Universal service); Mon, 29 Aug 2016 14:48:42 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 29 Aug 2016 14:48:42 -0700
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jon Callas <jon@callas.org>
In-Reply-To: <b1956113-b21a-f995-2e35-3011eb76ce8a@gmail.com>
Date: Mon, 29 Aug 2016 14:48:40 -0700
Message-Id: <8699AC5D-AD51-4287-A302-55CF9549A7FC@callas.org>
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>
To: Rene Struik <rstruik.ext@gmail.com>
X-Mailer: Apple Mail (2.3124)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-mAw8BJs9t9GMEATGleZ-_PBWUU>
Cc: "<tls@ietf.org>" <tls@ietf.org>, "David McGrew \(mcgrew\)" <mcgrew@cisco.com>, "cfrg@irtf.org" <cfrg@irtf.org>, Jon Callas <jon@callas.org>
Subject: Re: [TLS] [Cfrg] (confusing the issues) Re: 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 21:48:43 -0000

> 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