Re: [TLS] [Cfrg] 3DES diediedie

Hubert Kario <hkario@redhat.com> Thu, 25 August 2016 10:33 UTC

Return-Path: <hkario@redhat.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 1967712D7E0 for <tls@ietfa.amsl.com>; Thu, 25 Aug 2016 03:33:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.45
X-Spam-Level:
X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 UT66nGA0yG5n for <tls@ietfa.amsl.com>; Thu, 25 Aug 2016 03:32:59 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3BE912D7DF for <tls@ietf.org>; Thu, 25 Aug 2016 03:32:58 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 654C3C057FA5; Thu, 25 Aug 2016 10:32:58 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7PAWueT016761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2016 06:32:57 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Thu, 25 Aug 2016 12:32:56 +0200
Message-ID: <6377217.GbyXToEj0o@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.7-300.fc24.x86_64; KDE/5.25.0; x86_64; ; )
In-Reply-To: <E201DE55-20AF-4581-B502-5112DBA535A5@dukhovni.org>
References: <CAHOTMV+r5PVxqnSozYyqJqq_YocMKV06aAa-43t+5Huzh7Lo=A@mail.gmail.com> <CAHOTMVKBmDT-okm=ikECrotcEKS5fdn840-gV+5Tnx3eg4JBkQ@mail.gmail.com> <E201DE55-20AF-4581-B502-5112DBA535A5@dukhovni.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1918730.S5z2hGlNiR"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 25 Aug 2016 10:32:58 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FSosIR2x1ogiNxuNGD-az1p2Zls>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [TLS] [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: Thu, 25 Aug 2016 10:33:01 -0000

On Wednesday, 24 August 2016 22:59:23 CEST Viktor Dukhovni wrote:
> I am not opposed to a "diediedie" RFC, if that is likely to be helpful.
> For TLS, this ciphersuite is already comparatively rare, and perhaps its
> disappearance will not be sped up by a "diediedie" RFC?  Would an RFC
> help to prod vendors into action more than the already published findings?
> Would our collective energies be better focused on other, more pressing
> goals?

People that care for support of Windows XP or Windows 2003 will use 3DES 
either way. People that don't care about those OSes, are probably already 
doing everything to not negotiate it, if only to conserve TLS terminator 
resources.

When RC4 die-die-die was published, a lot of servers negotiated RC4 (because 
of BEAST), it's not the case with 3DES.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic