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

Dave Garrett <davemgarrett@gmail.com> Tue, 27 January 2015 23:15 UTC

Return-Path: <davemgarrett@gmail.com>
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 7BA7F1A912F for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 15:15:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 nqJ95qOmJ8Jk for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 15:15:25 -0800 (PST)
Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF6C1A9129 for <tls@ietf.org>; Tue, 27 Jan 2015 15:15:25 -0800 (PST)
Received: by mail-qa0-f48.google.com with SMTP id v8so13753732qal.7 for <tls@ietf.org>; Tue, 27 Jan 2015 15:15:24 -0800 (PST)
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-type:content-transfer-encoding:message-id; bh=Pu1wYfFd0uR0aSB3d934e/UCIsENGTQG5fxCcjYjVWI=; b=E+yEBcBD6jrf4LVxXmA4rDn3MkpcdTK4/19EvyUNZ9ZHAXeRlmLrSrhTyIP64vMJO6 djJy93K/P8+xhjr4ExOyFQRB/r6EqY3WwUOKzMgtyCAZaTLmNIywwKjLrOjrCCSKPOZb 5/LKVFVXuc4iLARl6V6yz9UIKQQr/HK4p1wgTFJ1ctKmAJ526OzvfIp2Ene7BSFMV0qb whjeAWxFmZgtAne20YaL/btfNactsNvi2mGClT8J+FBUcrbaKz/SO4/JyEvaP6cPXfZD wNQ1NAp4aQwq9rAzjAaV86NqdxYVHNZjV0JPY3459tTWaPRdvhrZWdQx38j0FZlIbn30 V3Jw==
X-Received: by 10.224.126.3 with SMTP id a3mr7182618qas.100.1422400524531; Tue, 27 Jan 2015 15:15:24 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-92-42-38.phlapa.fios.verizon.net. [72.92.42.38]) by mx.google.com with ESMTPSA id q5sm2399835qat.47.2015.01.27.15.15.23 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 27 Jan 2015 15:15:24 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Tue, 27 Jan 2015 18:15:22 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; )
References: <CAOgPGoD806Mf=wa76ixU15nGDCK91tgG4r3Sb0Us2meX4Rqk5A@mail.gmail.com> <54C7F106.9070400@azet.org> <CABkgnnUdbLnG_7DJLuVeNrK0Q2rDhNm2kRKbwMDAE7bmCr=JqQ@mail.gmail.com>
In-Reply-To: <CABkgnnUdbLnG_7DJLuVeNrK0Q2rDhNm2kRKbwMDAE7bmCr=JqQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201501271815.23083.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/VjOaIXdURwDthm5hEywe1SbdbuE>
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:15:27 -0000

On Tuesday, January 27, 2015 03:44:36 pm Martin Thomson wrote:
> On 27 January 2015 at 12:11, Aaron Zauner <azet@azet.org> wrote:
> > TLS 1.0 is only marginally different from SSLv3. I think a similar
> > document should exist for TLS 1.0. Yes I'm aware of the implications on
> > clients/servers.
> 
> I think that TLS 1.0 is nearing that point too.  But I'm not that
> enthusiastic about being the hitman there.  Well, not yet.

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.

A straw man proposal would be something like:

1) TLS 1.0 & 1.1 SHOULD NOT be supported by servers, effective immediately.
2) TLS 1.0 & 1.1 MUST NOT be supported by servers after X months.
3) TLS 1.0 & 1.1 SHOULD NOT be supported by clients after Y months.

I know the UTA BCP I-D deals with this area too, but a specific RFC from the
TLS WG might have more impact at reducing numbers before the inevitable
catastrophic vulnerability that warrants a diediedie RFC.


Dave