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. I took
a very quick look at RFC6066, but didn't found any real indication of what
will happen in future version, other than:
> Currently, the only server names supported are DNS hostnames;
> however, this does not imply any dependency of TLS on DNS, and other
> name types may be added in the future (by an RFC that updates this
> document). The data structure associated with the host_name NameType
> is a variable-length vector that begins with a 16-bit length. For
> backward compatibility, all future data structures associated with
> new NameTypes MUST begin with a 16-bit length field. TLS MAY treat
> provided server names as opaque data and pass the names and types to
> the application.
So, according to what you said and how the RFCs are written Pravin would
be right suggesting to limit the SNI fetch to TLSv1.2.
Anyway, even if we do this, its a good thing to separate the bugfix (relax
the record version check) and a change (only fetch SNI up to TLSv1.2) instead
of having both in a single commit.
So, should we do this? Should both record version and client_hello be checked
to be <= TLSv1.2?
Regards,
Lukas
