Re: [TLS] ClientHello record header version

What implementation are you working on? Section 5.1 says that, in
TLSPlaintext, the legacy_record_version "MUST be ignored for all purposes".
And, of course, any pre-1.3 middleboxes which hit this case are
non-compliant. That would imply they assume they can parse messages
following a ClientHello they did not produce, which is invalid.

I agree it would probably be prudent for the second ClientHello to say
0x0303, though. That's what our implementation does. We can fix the spec by
replacing some "ClientHello"s with "first ClientHello"s.

We did indeed come across a buggy non-compliant middlebox which paid
attention to the record-layer version for messages after a ClientHello it
did not produce. We didn't test subsequent client messages specifically, so
it's possible they only care about the server ones. That one was actually a
TLS-terminating middlebox, but their strategy for deciding when to
terminate involves sniffing the server response. (This is, of course,
non-compliant behavior. It is, again, invalid to assume that you can parse
anything following a ClientHello you did not produce. This middlebox did
not implement TLS 1.2 correctly.)

David

On Fri, Feb 2, 2018 at 1:22 PM R du Toit <r@nerd.ninja> wrote:

> In the process of testing my TLS 1.3 draft-23 implementation against
> OpenSSL (openssl.git:50ea9d2b3521467a11559be41dcf05ee05feabd6) I ran into
> an interoperability issue: the retry ClientHello record header version is
> set at 0x0301, while the ServerHello (HRR) and fake CCS records arriving
> from the server have record header version 0x0303.  I know this is
> according to the letter of the spec, specifically this sentence from
> Section 5.1:
>
>
>
> *In order to maximize backwards compatibility, records containing the
> ClientHello MUST have version 0x0301 and records containing the ServerHello
> MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2 respectively.*
>
>
>
> In diagram format:
>
> 0x0301:CH -->
>
> <-- 0x0303:SH(HRR)
>
> <-- 0x0303:CCS
>
> *0x0301*:CH(retry) -->
>
> <-- 0x0303:SH
>
> etc
>
>
>
> .. but I do think it will cause more issues down the line due to the
> record header version toggling between 0x0301 and 0x0303.  At the point in
> the handshake where the retry ClientHello is sent the "compatibility mode"
> changes have already served its purpose.  I believe some interop issues
> could be avoided by sending the retry ClientHello with record header
> version 0x0303.
>
>
>
> --Roelof
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>