Re: [Cfrg] [TLS] 3DES diediedie

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 25 August 2016 15:56 UTC

Return-Path: <prvs=7045e2e036=uri@ll.mit.edu>
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 9EB2612D1C2 for <cfrg@ietfa.amsl.com>; Thu, 25 Aug 2016 08:56:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.746
X-Spam-Level:
X-Spam-Status: No, score=-4.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, UNPARSEABLE_RELAY=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 1tptrPUV8CYP for <cfrg@ietfa.amsl.com>; Thu, 25 Aug 2016 08:56:14 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 903F812D135 for <cfrg@irtf.org>; Thu, 25 Aug 2016 08:56:14 -0700 (PDT)
Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u7PFqa7N029123; Thu, 25 Aug 2016 11:52:36 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Tony Arcieri <bascule@gmail.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
Thread-Topic: [TLS] 3DES diediedie
Thread-Index: AQHR/nWSg/CphhaeQ0GKsETs7Xni6qBZR4KAgAACuICAAIs4AA==
Date: Thu, 25 Aug 2016 15:56:04 +0000
Message-ID: <386DA563-FA77-4FA7-9E3D-EBF0022E0B43@ll.mit.edu>
References: <CAHOTMV+r5PVxqnSozYyqJqq_YocMKV06aAa-43t+5Huzh7Lo=A@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4D01F6E@uxcn10-5.UoA.auckland.ac.nz> <CAHOTMVKyub+J0Vx+UryDEAHdJRYRTmZ1wvLmEBkSor7pOrXy_w@mail.gmail.com>
In-Reply-To: <CAHOTMVKyub+J0Vx+UryDEAHdJRYRTmZ1wvLmEBkSor7pOrXy_w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.19.0.160817
x-originating-ip: [172.25.177.156]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha384"; boundary="B_3554970964_947430399"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-25_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608250187
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/VXp6x26WXF0mLXx6bpjWw4XC-Ys>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
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: Thu, 25 Aug 2016 15:56:17 -0000

>>  An attack that recovers cookie if you can record 785GB of traffic isn't anything I'm losing any sleep over.
>
> ..but is not a terribly dissimilar traffic volume to recover plaintexts from similar attacks against RC4,
> which received "diediedie" in RFC7465.
>
> Perhaps notable is the RC4 attacks work across multiple session keys, whereas SWEET32 requires the same key,
> but I think the practical consequences regarding data volume limits are similar.

I think this difference is crucial, because when the majority of the traffic was RC4, then scourging a lot of it and getting at least one key out of the attack seemed bad enough to do something about it. Hence RFC7465.

With 3DES, you need that much of traffic protected by the key you’re trying to attack. This completely removes any notion of practicality. I’m not losing my sleep over this either, and think this situation does not justify “diediedie”.