Subject: [TLS] ClientHello record header version

From: R du Toit <[email-masked]>
Date: Fri, 02 Feb 2018 13:22:06 -0500

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

---

From: David Benjamin <[email-masked]>
Date: Fri, 02 Feb 2018 18:48:46 +0000

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: R du Toit <[email-masked]>
Date: Fri, 02 Feb 2018 16:01:21 -0500

> What implementation are you working on? 

Proprietary, closed-source TLS stack.

>  Section 5.1 says that, in TLSPlaintext, the legacy_record_version "MUST be ignored for all purposes". 

Agree.  The interop issue was definitely on my side, and I was just using it as background for my question.

Section 5.1 also says: "This value MUST be set to 0x0303 for all records generated by a TLS 1.3 implementation other than the ClientHello".  With my "implementer's hat" on the word "MUST" implies that it must be enforced.

> And, of course, any pre-1.3 middleboxes which hit this case are non-compliant.

Indeed.  If BoringSSL already uses 0x0303 on the retry CH while OpenSSL uses 0x0301 then some (non-compliant) thing-a-ma-jig-in-the-middle will cause issues... and trigger the Universal Law of Users.