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

Brian Smith <brian@briansmith.org> Sat, 27 December 2014 23:37 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 7EFC01ACD08 for <tls@ietfa.amsl.com>; Sat, 27 Dec 2014 15:37:10 -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 MUh2vfbeFslF for <tls@ietfa.amsl.com>; Sat, 27 Dec 2014 15:37:09 -0800 (PST)
Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DAB1ACD03 for <tls@ietf.org>; Sat, 27 Dec 2014 15:37:09 -0800 (PST)
Received: by mail-oi0-f43.google.com with SMTP id i138so21035282oig.2 for <tls@ietf.org>; Sat, 27 Dec 2014 15:37:08 -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 :content-transfer-encoding; bh=q711ukirzPK75ALh+xb5L9ZOaGrZyXhzd0oW8YncH7s=; b=GNAElcUbQo1tVOhEso8uPF5PovypFzTJ8zhB+xx+G4YgxTsIBCZMIIQdKYk3G0gmDN CJzVjjmO4T5t71dtu+yAN+RAnwhaZeHTafNZyQNXat7RsbBV/duT15paJbMGsS0j1jDg yMvEODX3YtkSWzi6tYv5hbfKL6P8C8YXWN96le3vfpd3g97GMsBgBES/X0BatMenyg2h Jv/swrFQDAtKDuAaSlQ6t7wHkaTt89DPiPWEn0PL+fOJZTzoC5H1ndR+aEsgCBcFI8OO CPiz4dcDdttUh4q2su+GKWyL8VHSXeeZJmKVrEcNmYZ9Pd07pxYV3r5+B51DQrfJmqWQ E/QQ==
X-Gm-Message-State: ALoCoQnRm/ySHFvI1gc0PQPw5iOTCFmvPEEp1ZYfpXE3MAlGHdWoPqW3p0SWaeR3GDEMPeXcKpdt
MIME-Version: 1.0
X-Received: by 10.182.19.135 with SMTP id f7mr5494550obe.5.1419723428577; Sat, 27 Dec 2014 15:37:08 -0800 (PST)
Received: by 10.76.71.228 with HTTP; Sat, 27 Dec 2014 15:37:08 -0800 (PST)
In-Reply-To: <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com>
References: <201412221945.35644.davemgarrett@gmail.com> <F07340BA-F182-470C-AF90-C85A973075B9@gmail.com> <549F2D90.5030305@hauke-m.de> <201412271739.24476.davemgarrett@gmail.com> <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com>
Date: Sat, 27 Dec 2014 15:37:08 -0800
Message-ID: <CAFewVt6mZfOzZWSTMBGSPkUZEF377mv7NLss1rQxdGJD0hQ8ww@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JJ2eOFHdjSldughfcOHXol421tQ
Cc: Dave Garrett <davemgarrett@gmail.com>, "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: Sat, 27 Dec 2014 23:37:10 -0000

Yoav Nir <ynir.ietf@gmail.com> wrote:
> I see a "should" from Hauke and a "should not" from you. But using RFC 2119 words like “MUST NOT” in the spec could mean one of the following things:
>  1, That an SSLv2 ClientHello with version equal to whatever we choose for TLS 1.3 (0x03,0x04?) must be rejected and the connection closed.

The server should be required to (MUST) reject such a client hello, so
that we can make some extensions mandatory for the client to send.
(SSL2-compatible hellos cannot support extensions.) In particular,
signature_algorithms and SNI, at a minimum, should be mandatory to
send, at least for HTTPS clients.

>  2. That any TLS 1.3 implementation MUST remove support for SSLv2 ClientHellos.
>
>  3. That it is no longer prudent to even perform handshakes with clients that still offer SSLv2. In this case SSLv2 support is used as a proxy for insecure peer.

if the server is allowed to support TLS 1.0, then it should seems
reasonable for it to negotiate TLS 1.0 with a client that sent an
SSL2-compatible TLS 1.0 ClientHello. However, I think it is fine to
say that the server MUST NOT implement support for the SSL2 protocol.
And, it is fine to say that all TLS clients MUST NOT use
SSL2-compatible ClientHellos, since they wouldn't be able to add
extensions if they did.

Cheers,
Brian