Re: [TLS] Servers respond with BadRecordMac after ClientFinished, sent when PSK+EarlyData

 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 <xpepermint@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 <ilariliusvaara@welho.com> wrote:
>
> Ilari
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls