Re: [TLS] consensus on backwards compatibility changes

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
>