On Mon, Aug 8, 2022 at 11:52 PM Ilari Liusvaara <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. > > 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
