I investigated this issue and found that TTLS13::Client does not send EndOfEarlyData when 0-RTT. The transcript was invalid because it did not contain EndOfEarlyData.
By the way, I still have another question on this. I understand that if the server has not yet received EndOfEarlyData and it receives Finished, it should raise "bad_record_mac" alert and not ignore the lack of EndOfEarlyData. Because it assumes messages protected using keys derived from a "client_early_traffic_secret". Is my understanding of this correct? - https://www.rfc-editor.org/rfc/rfc8446.html#section-4.2.10 - > if the server fails to decrypt a 0-RTT record following an accepted "early_data" extension, it MUST terminate the connection with a "bad_record_mac" alert as per Section 5.2. - https://www.rfc-editor.org/rfc/rfc8446.html#section-4.5 - > This message indicates that all 0-RTT application_data messages, > After adding it, the error was gone and the connection closed with Alert(0). In that case, when adding "Connection: close" header, it should raise "bad_record_mac" alert, I wonder. For your reference, I created the client that does not send EndOfEarlyData when TLS 1.3 0-RTT Handshake. - https://github.com/thekuwayama/no_eoed_0rtt_client 2022年8月16日(火) 23:07 Kristijan Sedlak <[email protected]>: > > Hey Ilari, > > thank’s for replying. I did verify the transcript as well. Everything seems > to be correct. I bet if it wasn't the 1-RTT and 0-RTT(no-early-data) would > fail too. Something weird is going on only in 0-RTT(early-data) case. > > Can you maybe point me to an URL with the correct TLS1.3 implementation where > I could safely test the client? > > Best, > Kristijan > > On 9 Aug 2022, at 08:51, Ilari Liusvaara <[email protected]> wrote: > > Ilari > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
