@Eric Are you referring to this " ... completing the handshake with EndOfEarlyData following (which follows) the ClientFinished ..."? Well, I meant EOED and then ClientFinished. Anyhow, the client part seems to do it correctly.
Thx, Kristijan > On 10 Aug 2022, at 00:05, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Mon, Aug 8, 2022 at 11:52 PM Ilari Liusvaara <ilariliusva...@welho.com > <mailto:ilariliusva...@welho.com>> 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 > > <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 > > <http://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 > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
