Re: [TLS] consensus on backwards compatibility changes

[Joseph Salowey <[e-mail]>]

On Tue, Jan 27, 2015 at 10:49 AM, Martin Rex <[e-mail]> wrote:

> Joseph Salowey wrote:
> > Dave Garrett <[e-mail]> wrote:
> >
> > > On Sunday, January 25, 2015 02:36:14 pm Eric Rescorla 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.
> > >
> > > I don't recall any objections to #107, but not much discussion either.
> > >
> > > To sum it up here, in addition to some editorial changes:
> > >
> > > 1) Fixes initial ClientHello record layer version to { 3, 1 } (TLS
> 1.0) &
> > > mandates
> > > all other record layer versions to match negotiated version.
> > > (Brian's suggestion)
> > >
> > >
> > [Joe] I think this makes sense.  I added to comments to the PR.  I
> propose
> > to move the bit about the server accepting versions {3,x} to the same
> place
> > and change the wording of the existing test to say:
> >
> > "The client MUST set the version to {3, 1} for the initial ClientHello."
>
> The primary reason why several implementors goofed the TLS version
> negotiation in TLSv1.0 is that lack of clarity in the language.
>
> If your above statement refers to the client_version member of the
> ClientHello handshake message, please say so.
>
> The record layer version number is entirely independent from
> ClientHello.client_version, and for additional safety, it should be
> explicitly mentioned what requirements, if any, exist for the record
> layer protocol version of a record that carries the initial ClientHello
> of a connection.
>
>
[Joe] The text above is from the section describing the record protocol and
is referring to the version in the record layer of the protocol.  I agree
that it would be better to be explicit about this as it has generated
confusion in the past.



> The original idea behind the TLS protocol version negotiation was that
> the TLS handshake hash protects the entire handshake, and dirty hacks
> like the downgrade dance that contemporary browsers are doing, would
> be entirely unnecessary.
>
> It would be a pretty stupid idea for the TLSv1.3 protocol specification
> to withdraw TLS protocol negotiation protection from TLS clients, that
> for whatever reason, see a need to offer pre-TLSv1.0 protocols to servers.
>
>
[Joe] Agree, this is not what is being proposed.


> Defining an _implied_ set of features, that a TLS client sending/using a
> backwards-compatible ClientHello offering TLSv1.3 in
> ClientHello.client_version
> (or whatever alternative negotiation scheme the TLS WG chooses to use),
> would be *MUCH* more reasonable.
>
>
[Joe] I'm not sure what you mean.



>
> -Martin
>