Re: [TLS] consensus on backwards compatibility changes

Eric Rescorla <ekr@rtfm.com> Sun, 25 January 2015 19:36 UTC

Return-Path: <ekr@rtfm.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 6B2A41A1A30 for <tls@ietfa.amsl.com>; Sun, 25 Jan 2015 11:36:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 6TWRAdQR-Xfd for <tls@ietfa.amsl.com>; Sun, 25 Jan 2015 11:36:56 -0800 (PST)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A631A1A2F for <tls@ietf.org>; Sun, 25 Jan 2015 11:36:56 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id y19so5745332wgg.11 for <tls@ietf.org>; Sun, 25 Jan 2015 11:36:55 -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:from:date :message-id:subject:to:cc:content-type; bh=UWdXYsOmqpZq7aUvmj3YPyfctqovZo9qqyWc9w+wtEM=; b=RKXCcMtrM0LD+jSdIkz1Xhu/hzS7nqUTOXPRM3JV1bcu9F7ZEEKbLTZBNYY1WhbSyR U8u7fs2OyIEICcl9aHG7n7OJDM8OuhYpaJtNSLTTtbAOJc9I/QbsS/puF1jmDlmDcbXi HvYmUvJMecACq+HhRHPQHMar4CFIA2Tjx/ZzZ7wLjbTOz2Mc8SPZdTXoxa+CWU/yJ9Ry Pk0dUbWfU+TiFno85nOEBcbEZziDtPgPFMxQpY2EbfxgJXJpLkwhUKlAYkaeqdkjiq5w iZawsUDhFK1A1KzmKamfsQBTLUp+Ox7CpvwTekC1X7gKDpIBk4Q/qIX+Hs9rSV4b9gFk IWMg==
X-Gm-Message-State: ALoCoQnBZgMPY/cVwsa8Ssi1GolxP6JIugfa7m3WicVubHBZApn3dNB3yk221FD1k+LrauRI2pEP
X-Received: by 10.180.98.162 with SMTP id ej2mr25385180wib.39.1422214614955; Sun, 25 Jan 2015 11:36:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Sun, 25 Jan 2015 11:36:14 -0800 (PST)
In-Reply-To: <201412300503.03923.davemgarrett@gmail.com>
References: <201412300503.03923.davemgarrett@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 25 Jan 2015 11:36:14 -0800
Message-ID: <CABcZeBPujH595MjfRDstnaDk5fmQVi4qi+-nUhu5zh3L4CxUgw@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary=f46d04428274eb4efc050d7f24d0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/T7EAAsHhTVZuCPbEvFGDgpqk54U>
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] consensus on backwards compatibility changes
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, 25 Jan 2015 19:36:58 -0000

Based on reading the mailing list, it seems to me that there is rough
consensus
on PR#105, but not (yet?) on PR#107.

Chairs,
I'd like to merge PR#105. Do you agree that there is consensus? If so,
I will merge.

Can you please advise on how you would like to proceed on PR#107?

-Ekr




On Tue, Dec 30, 2014 at 2:03 AM, Dave Garrett <davemgarrett@gmail.com>
wrote:

> Per Brian's suggestion, I've split the topic of full prohibition of SSL v2
> CLIENT-HELLO usage into its own issue, as there is clearly no consensus on
> this
> yet. It would be really nice if some real-world stats on how much this is
> actually used could be provided. (I think continued acceptance of it is
> illegitimate, but hard data is harder to argue with)
>
> Issue #113 Prohibit SSL v2 CLIENT-HELLO entirely
> https://github.com/tlswg/tls13-spec/issues/113
>
> I have heard notable support for this, including Eric, but I do concede
> there
> might be too much desire for infinite backwards compatibility to reach
> consensus.
> I'm still hopeful we can come to an agreement that two decades is a
> sufficient
> deprecation period. :/
>
> I have two PRs for the backwards compatibility section.
>
> The first has all SSL backwards compatibility changes. In addition to RFC
> 6176
> SSL 2 language, I've added SSL 3 negotiation prohibition as per Martin's
> suggestion (based on the current I-D). The v2 hello documentation is cut
> out,
> but seeing as it's only valid for prior versions, prior RFCs can be
> referenced
> if needed.
>
> PR #105 remove SSL 2 backwards compatibility section & prohibit SSL
> negotiation
> https://github.com/tlswg/tls13-spec/pull/105
>
> The second PR has more general backwards compatibility section
> improvements,
> prohibition of RC4 (also based on its current I-D), and Brian's ClientHello
> version freeze proposal. Currently, I have the ClientHello version listed
> as a
> "MUST", but I leave for the possibility that a "SHOULD" might be
> appropriate if
> other tactics for dealing with buggy servers should continue to be
> permitted.
> Feedback from Microsoft, Oracle, or anyone else implementing alternate
> workarounds here would be greatly appreciated.
>
> PR #107 revise backwards compatibility & fix ClientHello version
> https://github.com/tlswg/tls13-spec/pull/107
>
> Note that the SSL3 & RC4 language based on current drafts is of course
> contingent on those being passed successfully, though this is generally
> expected.
>
> Both PRs update the Informative References as needed, which I've hopefully
> done
> correctly.
>
>
> Dave
>