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

Dave Garrett <davemgarrett@gmail.com> Mon, 29 August 2016 17:03 UTC

Return-Path: <davemgarrett@gmail.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 1A79512D5F2 for <tls@ietfa.amsl.com>; Mon, 29 Aug 2016 10:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 U_yXVNYOR3_H for <tls@ietfa.amsl.com>; Mon, 29 Aug 2016 10:03:51 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 26F8312D098 for <tls@ietf.org>; Mon, 29 Aug 2016 10:03:51 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id z190so144242648qkc.0 for <tls@ietf.org>; Mon, 29 Aug 2016 10:03:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=p84lw8XM4/W58vlvYbcvxxT5BFiQVg5H5AEefrc1pv8=; b=IBeKjTHQ+R9S2AmxKhIbM7gFK5qukioYTH+8O0XXgYa1jtgNS6LTU1Pe7iP3XGr5/O dazYRvLd/cyrwsMuVJwhplO4nTPTCIQ7mIX2rbfd1+rzC3pvxceKuyu2+EURpbACqIJG q1sQ18QdD5CfRcn3QOff+85qalw7hYpaGRCOTGngeefvjuX517pisN0uA6ec9zF5Xj4u YHmxzzIchIqUV7gH17+ZK+zCiLGfbE5gwqsPe5+xGXW4g2rHnzLL3SoNDYtAW5/oxQcR W44D69LdPbw4Q51Ah5ToyPmgYBFQjQpM/7QTqDp4the3gnhwfwy2uiWbOfY+Ya5kFaJ7 MLFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=p84lw8XM4/W58vlvYbcvxxT5BFiQVg5H5AEefrc1pv8=; b=Ld/iF6iiUQRYBkujX9U1Lq8rQWXLZmqXaCvFcZaCg2ZZODRBlu5uKR1e5bxdTGzc79 TDxE4FJIzGKgrt/QKIFAwn1WLmx10FdBAtsRDChSJMTd2+uHx9HHQSliVDyUpHAMk7c1 eIyRNtW2rRolOA+CmHp0x8SxVekmxfZliaCugaKQlMBC1MenVNL9cf/1tt/RMTzXKk+o EPzBhJ+iGPEByXR3l92b9ZsgRrEFso+SJCjrRB0/Bh1r33D/BA1E49ZmBcBFc/0XBC5S cOXs1OLvreosj/fK47T5wf8UAtJUpTbUAAQXgZIlQSHaMi2RhK3dIMHt0cafSFFSKaNG gv7w==
X-Gm-Message-State: AE9vXwNU7wyhwKuRJufCLJKstSPIoLFr5Cjoc5FjbEOkCQDk/gdxcr+I4mHCcGZpefTjgA==
X-Received: by 10.55.41.86 with SMTP id p83mr20307841qkh.93.1472490227194; Mon, 29 Aug 2016 10:03:47 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id v68sm19054502qkd.9.2016.08.29.10.03.46 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 29 Aug 2016 10:03:46 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Mon, 29 Aug 2016 13:03:45 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CAHOTMV+r5PVxqnSozYyqJqq_YocMKV06aAa-43t+5Huzh7Lo=A@mail.gmail.com> <57C43102.7090902@secworks.se> <b1956113-b21a-f995-2e35-3011eb76ce8a@gmail.com>
In-Reply-To: <b1956113-b21a-f995-2e35-3011eb76ce8a@gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201608291303.45728.davemgarrett@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/twAB9sLLl9qk_aZJ7ckiLFJ905Q>
Cc: "David McGrew \(mcgrew\)" <mcgrew@cisco.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [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 17:03:53 -0000

Within this line of thought, an unlimited-key-use-diediedie would have far more value. An RFC precisely defining a set of key data limits would address both this 3DES issue as well as AES and any other cipher. As cited on https://sweet32.info/ , data limits is a primary way Mozilla is dealing with this attack.


Dave


On Monday, August 29, 2016 09:26:18 am Rene Struik 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).
> 
> Rene
> 
> On 8/29/2016 8:56 AM, Joachim Strömbergson wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > 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...