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

[Eric Rescorla <[e-mail]>]

On Mon, Aug 8, 2022 at 11:52 PM Ilari Liusvaara <[e-mail]>
wrote:

> On Mon, Aug 08, 2022 at 08:15:41PM +0200, Kristijan Sedlak wrote:
> > Hello everyone.
> >
> > I decided to get involved here since I hit a dead end when resolving
> > an Alert(20) error that I get from almost all servers when using PSK
> > with EarlyData.
> >
> > Here's the initial issue I opened
> https://github.com/thekuwayama/tttls1.3/issues/48.
> > It relates to a specific implementation but my questions are general.
> > There's also a code snippet that you can run and see the issue
> > yourself.
> >
> > So it happens that when sending a GET request as EarlyData and then
> > completing the handshake with EndOfEarlyData following the
> > ClientFinished message, a server (e.g. ssltest.louis.info)
> > successfully sends a complete response but finishes the request with
> > Alert(20) message. It doesn't happen on 1-RTT nor 0-RTT(without early
> > data). If I don't send ClientFinished in 0-RTT+EarlyData I don't get
> > Alert(20) and everything works as expected.
> >
> > I don't see anything in the spec that would describe something like
> > this or would point to a different way for calculating the
> > ClientFinished for 0-RTT+EarlyData case. Is maybe this sentence from
> > the spec "PSK-based authentication happens as a side effect of key
> > exchange." something that some of us miss interpreter and states
> > that Finished message should be verified and sent only in 1-RTT?
> >
> > What could be the case here?
>
> Wild guess, the transcript is not computed over correct messages or in
> correct order.
>
>
> When server accepts early data, the sequence of messages client sends
> is:
>
> - ClientHello
> - (0-RTT data)
> - EndOfEarlyData
> - client Finished
>

I just want to flag this in case it got missed. EOED precedes
ClientFinished, but your original
message says the opposite.

-Ekr


>
> And the sequence of messages in transcript used to compute the client
> finished is (note the EoED, RFC 8446 section 4.4.1 is very explicit
> about it):
>
> - ClientHello
> - ServerHello
> - EncryptedExtensions
> - server Finished
> - EndOfEarlyData
>
>
> (This assumes there is no extension that would add new messages in
> play. There can not be HelloRetryRequest because that implicitly
> rejects early data.)
>
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>