IETF Logo Mail Archive

Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00

Hanno Böck <hanno@hboeck.de> Tue, 27 January 2015 23:34 UTC

Return-Path: <hanno@hboeck.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026CD1A914F for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 15:34:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 UwFmToGvD6Jb for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 15:33:59 -0800 (PST)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5F31A914D for <tls@ietf.org>; Tue, 27 Jan 2015 15:33:59 -0800 (PST)
Received: from pc (ip5b4003d1.dynamic.kabel-deutschland.de [::ffff:91.64.3.209]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 28 Jan 2015 00:33:57 +0100 id 0000000000000026.0000000054C82065.000002B3
Date: Wed, 28 Jan 2015 00:33:56 +0100
From: Hanno Böck <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20150128003356.41d2899b@pc>
In-Reply-To: <201501271815.23083.davemgarrett@gmail.com>
References: <CAOgPGoD806Mf=wa76ixU15nGDCK91tgG4r3Sb0Us2meX4Rqk5A@mail.gmail.com> <54C7F106.9070400@azet.org> <CABkgnnUdbLnG_7DJLuVeNrK0Q2rDhNm2kRKbwMDAE7bmCr=JqQ@mail.gmail.com> <201501271815.23083.davemgarrett@gmail.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-691-1422401637-0001-2"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/MwAlIJQx0_-jtkMLscT6pGj48tc>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 27 Jan 2015 23:34:01 -0000

On Tue, 27 Jan 2015 18:15:22 -0500
Dave Garrett <davemgarrett@gmail.com> wrote:

> Is it at all practical to publish an TLS RFC stating intent to
> deprecate TLS 1.0/1.1 within some fixed timeframe? I think everyone
> would rather phase it out then have to "be the hitman" each time.

I think if the deprecation of SSLv3 shows one thing it is that we need
to start now if we want to deprecate it in several years.

There are products on the market developed as late as 2011 that only
support SSLv3. I think a crucial thing would be to identify and stop
people from deploying TLS 1.0-only solutions today - so we won't have
them tomorrow when we really need to deprecate TLS 1.0.

It's a topic I've been discussing with a number of people lately. Ideas
welcome. I thought about adding something to webpages that will warn
users if they connect with anything != TLS 1.2. That could at least
make people aware if they surf with deprecated technology.


P.S.: +1 from me for the sslv3-die-draft. The sooner this gets out the
better.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

v2.29.0 | Report a Bug | By Email | System Status