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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
