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
>
>