Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft

Brian Smith <brian@briansmith.org> Sun, 28 December 2014 01:38 UTC

Return-Path: <brian@briansmith.org>
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 C342E1ACE76 for <tls@ietfa.amsl.com>; Sat, 27 Dec 2014 17:38:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 P56uB-QvXFt7 for <tls@ietfa.amsl.com>; Sat, 27 Dec 2014 17:38:57 -0800 (PST)
Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966AE1ACE75 for <tls@ietf.org>; Sat, 27 Dec 2014 17:38:57 -0800 (PST)
Received: by mail-oi0-f52.google.com with SMTP id h136so25720369oig.11 for <tls@ietf.org>; Sat, 27 Dec 2014 17:38:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fiqrQyCKtbLm2JHXkIhkHs4i7EPpm71e7wwjkYpVXME=; b=KldzzMpELEUt4ljRkT90X1ZoL9zNdPqz60yEcZc/gJ6nKOCDH13h5kYhMl7qFML25b ugRbCKZ/9OGmnVovxhfMR3AKvRtfCpWUNKVdoUk2VDF6qsXkyP1CroPHY4hJ9oRXt/EI CC3VFnCYwryUVxwUEWnAyY4/eWuEJli/4UvI/HwzYxxUX/Bgwn/7kndlez12eFO3Xjvh lDM16bMZXHMK5lsakXvTBr0Wq5RJ6Vau+RXeOE3a2ir2IW/ncGnBKzKvgNOp94WmXqyB /U9LQoUgb/FYnp99ekscv12FVB/gkTwFKbQon9hukOsDcpzLyWcSPrraUiAr1cGvbyDU 6HDg==
X-Gm-Message-State: ALoCoQmmx+r5EuMGJM2Pi8aB6pb+3qMG2jErQwl0mjTQRuwVotCgyk9HG2NBOFwxYAksSds2tpSR
MIME-Version: 1.0
X-Received: by 10.60.124.69 with SMTP id mg5mr29270881oeb.73.1419730736924; Sat, 27 Dec 2014 17:38:56 -0800 (PST)
Received: by 10.76.71.228 with HTTP; Sat, 27 Dec 2014 17:38:56 -0800 (PST)
In-Reply-To: <201412272007.52081.davemgarrett@gmail.com>
References: <201412221945.35644.davemgarrett@gmail.com> <201412271906.00820.davemgarrett@gmail.com> <CAFewVt4xv7cgr9pB=Rt=kvHh0kQ0-PH-RBvi4i=HrQBhZatL7w@mail.gmail.com> <201412272007.52081.davemgarrett@gmail.com>
Date: Sat, 27 Dec 2014 17:38:56 -0800
Message-ID: <CAFewVt6sMiUsV3bR+b99rVRVeOHc9OQGYk6DEK73QaX6_v77yA@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VN9HJsiKdj4QhFkW0mYJDb605QI
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft
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: Sun, 28 Dec 2014 01:38:59 -0000

Dave Garrett <davemgarrett@gmail.com> wrote:
> On Saturday, December 27, 2014 07:39:07 pm Brian Smith wrote:
> I'm hesitant to even mention it, but obviously my next most preferred route is
> obviously to do that and make acceptance of an SSL2 hello for older TLS versions
> a SHOULD NOT rather than a MUST NOT.

That seems good to me.

> That, however, is basically just RFC 6176 with a wag of a finger thrown in.

That's good, because it should be easy for everybody to accept.

> There have been bugs caused by supporting this and it should be mandated to no
> longer be usable for all implementations. Anyone actually relying on it and not
> capable of flipping the client-side switches needed to stop it is not likely to
> be a candidate for early adoption of TLS 1.3, anyway.

Servers generally cannot flip switches on the client.

I want TLS 1.3 to be deployed widely and quickly after it's been
standardized, and I want people to be able to put it into production
use during the standardization effort so we get the same kind of
interop testing that HTTP/2 got. This requires that the TLS 1.3 spec
should try to avoid breaking how earlier versions of TLS work, unless
there is a very strong reason to do so.

Cheers,
Brian