Dear all,
bringing up this thread again ....
In the course
of studying the way TLS implementations treat the "version" (or
"legacy_record_version") field in the record header, we were wondering
(please excuse if we missed some arguments here from past discussions):
(1)
What is an implementation (in particular when receiving the first bytes
over a new connection) supposed to do if the record's version field
signals a protocol version the implementation does not support? I
understand that, at this stage, enforcing a specific value (e.g. 0x0301
according to the TLSv1.3 draft) is detrimental to interoperability.
However, if that field bears any meaning (in either TLSv1.3 or previous
versions), what is it? I would expect this field is supposed to allow
signaling a potentially non-backward compatible record format
(inauspiciously interfering with a receiver disregarding the record
version). Provided this field isn't treated as an enum, what about
checking/enforcing at least the major version as BoringSSL does (as far
as I know)? In any case, I would propose to be very clear about this in
the text (my sense was that there is some work in progress, but I
couldn't find anything). In implementations (<TLSv1.3), we found all
kinds of interpretations.
(2) What is an implementation (up to
TLSv1.2, as the TLSv1.3 spec is rather clear about that) supposed to use
for the record's protocol version field before a version has been
agreed upon (e.g. when sending an alert after receiving an unparsable
ClientHello)? My best guess would be to set it to the lowest (TLS)
protocol version that uses the same record format (probably 0x0301).
However, we observe several servers which, in such cases, answer with an
alert with weird record protocol version values, e.g. 0x0000.]
Thanks and Cheers,
Andi
___________________________________
Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany
>>> Benjamin Kaduk <bka...@akamai.com> 11/10/16 5:22 PM >>>
On 11/08/2016 06:25 PM, Martin Thomson wrote:
On 9 November 2016 at 05:59, Brian Smith <br...@briansmith.org>
wrote:
This isn't a pervasively shared goal, though. It's good to let
the browsers
police things if they want, but I think a lot of implementations would
prefer to avoid doing work that isn't necessary for interop or security.
If you permit someone to enforce it, then that is sufficient. I
don't
think that we should ever force someone to enforce these sorts of
things (as you say, sometimes strict enforcement isn't cheap or even
desirable).
Agreed. We should probably change the text a bit, though, as right
now readers can get two different readings depending on whether they go for
a strict decode_error (or illegal_parameter?) since the struct doesn't
match the definition, or follow the "MUST be ignored for all purposes".
-Ben
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
