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

@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 <ekr@rtfm.com> wrote:
> 
> 
> 
> On Mon, Aug 8, 2022 at 11:52 PM Ilari Liusvaara <ilariliusvaara@welho.com <mailto:ilariliusvaara@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>