Alright, 1. I tested 0-RTT+EarlyData by removing EOED from the transcript - has no effect. This should fail, but it seems that the server goes processing ED immediately and forgets about the rest of the handshake. 2. It's very hard to find a server that accepts EarlyData. I searched the web and found only 2. Sadly, both work the same way. Maybe they use the same (faulty, early) server implementation. 3. Makes sense regarding the connection close header behavior.
My conclusion is that since a) 1-RTT and 0-RTT+NoEarlyData work and 2) 0-RTT+EarlyData should work the same way except that the transcript includes an additional message, and 3) I verified the code and I'm sure that the transcript on the client's side is correct, the issue must be on the remote server (to which I don't have access). I guess we can mark this thread as resolved. Thanks for your help! Kristijan > On 9 Aug 2022, at 18:16, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > On Tue, Aug 09, 2022 at 09:05:31AM +0200, Kristijan Sedlak wrote: >> >> 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. > > Well, if an implmentation incorrectly omitted EOED from transcript, that > would only fail in accepted early-data case, not in other cases. > However, looking at the library source, it seems to properly include > EOED in the transcript (however, I am not a Ruby programmer). > > > Wild thing to try, and extremely unlikely to work, but does removing the > EOED from the transcript (but still sending the message!) make the > server accept the client finished? If yes, the server is buggy: TLS 1.3 > is very clear that EOED is part of the transcript. > > >> Can you maybe point me to an URL with the correct TLS1.3 >> implementation where I could safely test the client? > > Well, I would try testing against some major CDN that accepts early > data, as they likely have the most debugged server implementations. > As for safety, if you don't have automated repeats, I would think that > would be unlikely to trip any sort of attack detection with the CDN. > > I have written a TLS implementation, but it will not support early > data. > > > On Tue, Aug 09, 2022 at 09:55:37AM +0200, Kristijan Sedlak wrote: >> After some sleep, I went playing with the content of the EarlyData >> sent to the server and it turned out that the "Connection: close" >> header must be present in the HTTP1.1 request. After adding it, the >> error was gone and the connection closed with Alert(0). > > Well, what I think is happening here is that the server can only ever > send one alert per connection. The Connection: close then causes it > to send close_notify from early data, and so when the finished MAC is > bad, it can not send alert for it. Or else that the close from early > data causes it to get confused and silently abort the handshake. > >> Is this the expected behavior and Keep-Alieve is not allowed when >> EarlyData is used or it's just the remote server implementation >> specific? If I understand the spec correctly, the behavior of the >> EarlyData part is mostly up to the implementor, and you must know >> the rules up front, right? > > Keep-Alive is definitely supposed to work with early data. > > The behavior specified is that if early data is accepted, the > client data consists of concatenation of the early data and the > application data the client sends. If early data is not proposed, or > it gets rejected, then client data consists of application data the > client sends. > > > Note that for HTTP, only GET and HEAD (and in future, QUERY) are > allowed in early data. And the requests might get 425 error, which > MUST be retried. > > > > -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
