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 <xpeperm...@gmail.com>: > > 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 <ilariliusva...@welho.com> wrote: > > Ilari > > > _______________________________________________ > 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
