Re: [TLS] consensus on backwards compatibility changes

Ira McDonald <blueroofmusic@gmail.com> Tue, 27 January 2015 17:33 UTC

Return-Path: <blueroofmusic@gmail.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 8DDA01A8854 for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 09:33:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Z78MYoe18djI for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 09:33:36 -0800 (PST)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5395B1A1A94 for <tls@ietf.org>; Tue, 27 Jan 2015 09:33:36 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id h11so6585735wiw.1 for <tls@ietf.org>; Tue, 27 Jan 2015 09:33:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jrljTCB3gzZI2++8Het9jMWoDbY7D5wQ9rX2duSyMik=; b=fVrqt7FoSkWK+1PrremMypIiyUMLAX/e9IHX//gCbjC3CIwgw0+tgeUQeu5Taa9Sem 86sVvqWEI+Lw5rhFiAPl2xoZaIcDwvsG7WjP1Lh/LGPilIHPAjkIUuqlmWnho1teBcGq UJ7rJsGRnzj8h+x/1gPtY6kq2BiGfKdC3rITpDbkTOaXoYZ3A4NeHRc1n6lRwWMGEeRz cwdjRTp3UQ5RYzvX/2AjTBGFRFyd+KAZnlici3XqVscUqaYKhdERWDt8hYM3MTG0O6zU 1CT4uDi95KTEcvMX4GiYGpKMziQ4AnpvgAl7Qkhlprtb2doOdq3zyvsDyYuRGKvOiVFL AioA==
X-Received: by 10.180.108.165 with SMTP id hl5mr39131296wib.39.1422380014992; Tue, 27 Jan 2015 09:33:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.32.77 with HTTP; Tue, 27 Jan 2015 09:33:14 -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: Ira McDonald <blueroofmusic@gmail.com>
Date: Tue, 27 Jan 2015 12:33:14 -0500
Message-ID: <CAN40gSsuJ5ZC12AgobDcv0jPn=Pg2Mizwigw=sXTqWXv8t+BLQ@mail.gmail.com>
To: Sean Turner <turners@ieca.com>, Ira McDonald <blueroofmusic@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f3ba1018839ff050da5a786
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/6BhAiN_1IJpSojOreGz4F7TbFeI>
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: Tue, 27 Jan 2015 17:33:39 -0000

Hi Sean,

With respect, "are NOT RECOMMENDED" is a passive voice
synonym for active voice "SHOULD NOT" (and terrible English).

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434


On Tue, Jan 27, 2015 at 12:21 PM, 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 mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>