Hi Lukas,
On Fri, Apr 11, 2014 at 03:17:32PM +0200, Lukas Tribus wrote:
> Hi,
>
> > It's not a matter of opinion but specification. If the packet format is
> > specified as being exclusively for 3.0..3.3, then we should only match
> > this. If it's specified as part of TLS for which only versions 3.0 to
> > 3.3 are currently defined, then we must apply the default rule specified
> > for the whole protocol according to how to handle newer versions. All
> > protocols generally indicate how newer versions must be handled, and
> > it's important to stick on the rule they dictate in order not to break
> > interoperability with future clients.
>
> Mmmmh, good point.
>
>
> TLS extensions are documented pretty strictly against certain TLS version:
> RFC3546 --> TLSv1.0
> RFC4366 --> TLSv1.0 and TLSv1.1
> RFC6066 --> TLSv1.2
>
> I'm not sure that those RFCs really address forward compatibility.
Well, I have a different interpretation of this. First, 2246 clearly says
that TLSv1.0 has major 3 and minor 1 because it's a minor improvement over
SSLv3.0. So that clearly states that a change of the minor here only means
a minor improvement.
Second, 3546 discusses extensions and says :
"The extensions may be used by TLS clients and servers. The
extensions are backwards compatible - communication is possible
between TLS 1.0 clients that support the extensions and TLS 1.0
servers that do not support the extensions, and vice versa."
This implies forward compatibility since both sides may use extensions
in a backwards compatible way with the other one. Otherwise, lack of
forward compatibility would break this type of backwards compatibility.
5246 says this :
"Appendix E. Backward Compatibility
E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0
Since there are various versions of TLS (1.0, 1.1, 1.2, and any
future versions) and SSL (2.0 and 3.0), means are needed to negotiate
the specific protocol version to use. The TLS protocol provides a
built-in mechanism for version negotiation so as not to bother other
protocol components with the complexities of version selection.
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
compatible ClientHello messages; thus, supporting all of them is
relatively easy. Similarly, servers can easily handle clients trying
to use future versions of TLS as long as the ClientHello format
remains compatible, and the client supports the highest protocol
version available in the server.
A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol."
Again, to me it clearly states that the focus is on supporting different
versions on both sides, which implies that a client talking 1.2 can be
understood by a server talking 1.1 etc...
I see nothing in these specs mandating a limit to a certain protocol
level for certain features. All I'm seeing is "protocol version is
{ 3, 3 } for this version of the spec" in 1.2, or "{ 3, 2 }" for 1.1,
etc... It just reminds what to *emit* to indicate what protocol you're
speaking, not anything related to a sudden drop of forwards compatibility.
So in my opinion, since the protocol is designed to be backwards and
forwards compatible, and uses minor version for newer extensions, there
is no reason for limiting ourselves to TLSv1.2 for extensions that
exist since 1.0 and will certainly continue to be supported by later
version, at least for backwards compatibility.
Regards,
Willy
