Re: [TLS] consensus on backwards compatibility changes
Eric Rescorla <ekr@rtfm.com> Thu, 12 February 2015 19:43 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 7A2DB1A1BF2 for <tls@ietfa.amsl.com>; Thu, 12 Feb 2015 11:43:38 -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 O82bBOnQIdvE for <tls@ietfa.amsl.com>; Thu, 12 Feb 2015 11:43:35 -0800 (PST)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CCF1A1B6A for <tls@ietf.org>; Thu, 12 Feb 2015 11:43:35 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id hi2so7043990wib.0 for <tls@ietf.org>; Thu, 12 Feb 2015 11:43:33 -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=fkva658OK6G4X/PoeyCwZ8+VdtqmeMzYsDVlMaWTwls=; b=T7q/HezUa/eivo2MIazCQPtKtkRV7Z88X2+4kPejKWhqA0n8u/7JY+pPutQBd89srY I7tUNJpbm10pbeuUF4VTz2pkGC4xgHcHM4wqYKuVSzPZI/1FIoAeyC46S4uWuQErPlcr u6wfNNlJ/mYHrUshJRDZyQWxKMdU8SenJb40xdNclgB1CMvsYD/P6QOEKKXdRYfOsMO0 njyLa4YPYUoOVxrtDSBlZDsy5U0zTJqr8VHKydF9kf7BeIQVqd5pOvYQyMS9crvO8gGH B66M5PXI26kxbyrVPiXORSfgS5R6XqcAo3DDOSY7xl5l49LWIfzGvbSFlYCtoN7NWwRM 6Upg==
X-Gm-Message-State: ALoCoQlb3N8qF/5XI8KHN5d0EqSGwnE5/uij3rdb/2cTTrNMs1ejxXAsTGZLdIBch/Kysp8tdrkp
X-Received: by 10.194.122.38 with SMTP id lp6mr11693552wjb.24.1423770212683; Thu, 12 Feb 2015 11:43:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.219.205 with HTTP; Thu, 12 Feb 2015 11:42:52 -0800 (PST)
In-Reply-To: <83CBC7E2-CDC9-4EDD-8648-8C80EE588343@ieca.com>
References: <201412300503.03923.davemgarrett@gmail.com> <CABcZeBPujH595MjfRDstnaDk5fmQVi4qi+-nUhu5zh3L4CxUgw@mail.gmail.com> <83CBC7E2-CDC9-4EDD-8648-8C80EE588343@ieca.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 12 Feb 2015 11:42:52 -0800
Message-ID: <CABcZeBPzkPgUa2vB4N_peBUeKsypvp_bOUr+9bvW8SfmML7zNw@mail.gmail.com>
To: Sean Turner <turners@ieca.com>
Content-Type: multipart/alternative; boundary="089e01227ee4c4f4a3050ee95573"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/BD6hdt031kX5JC_f1PjjR4mQhaQ>
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: Thu, 12 Feb 2015 19:43:38 -0000
I have merged PR#105. I am awaiting chair guidance on PR#107. -Ekr On Tue, Jan 27, 2015 at 9:21 AM, Sean Turner <turners@ieca.com> wrote: > We believe that what’s reflected in PR #105 reflects list consensus. But, > we (as chairs) have a couple of thoughts: > > 0) We both hate “MAY” requirements language. We’d prefer that the > following be reworded (this is just a starting point): > > OLD: > > Implementations MAY accept an SSL version 2.0 compatible > CLIENT-HELLO in order to negotiate older versions of TLS, > however this is not recommended. > > NEW: > > Implementations are NOT RECOMMENDED to accept an > SSL version 2.0 compatible CLIENT-HELLO in order to > negotiate older versions of TLS. > > note that the using “NOT RECOMMENDED” also means we need to add that to > the 2119 language clause but we can do that later. Basically: > > s1.1: OLD: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > NEW: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT”, > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED”, > "MAY", and "OPTIONAL" in this document are to be interpreted as described > in RFC 2119 [RFC2119]. > > 1) We’d like to make it crystal clear in the SSL3.0 text whether you’re > talking about the hello version or record version. We’re pretty sure that > “protocol version” in the following is the hello version but we think that > should be made clear. > > Implementations MUST NOT send a ClientHello or ServerHello with > the protocol version set to { 3, 0 } or less. Any endpoint receiving a > Hello message with the protocol version set to { 3, 0 } MUST respond > with a "protocol_version" alert message and close the connection. > > spt > > On Jan 25, 2015, at 14:36, Eric Rescorla <ekr@rtfm.com> wrote: > > > 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 > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > >
- [TLS] consensus on backwards compatibility changes Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Eric Rescorla
- Re: [TLS] consensus on backwards compatibility ch… Kurt Roeckx
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Kurt Roeckx
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Kurt Roeckx
- Re: [TLS] consensus on backwards compatibility ch… Joseph Salowey
- Re: [TLS] consensus on backwards compatibility ch… Sean Turner
- Re: [TLS] consensus on backwards compatibility ch… Ira McDonald
- Re: [TLS] consensus on backwards compatibility ch… Martin Rex
- Re: [TLS] consensus on backwards compatibility ch… Martin Rex
- Re: [TLS] consensus on backwards compatibility ch… Joseph Salowey
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Florian Weimer
- Re: [TLS] consensus on backwards compatibility ch… Martin Rex
- Re: [TLS] consensus on backwards compatibility ch… Florian Weimer
- Re: [TLS] consensus on backwards compatibility ch… Eric Rescorla
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Michael Clark
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Nikos Mavrogiannopoulos
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Ilari Liusvaara