To add to the list of issues, DTLS 1.3 says very little about 0-RTT, but skipping early data is very different between TLS and DTLS. In particular, I think Appendix D.3 just doesn't apply to DTLS 1.3. DTLS 1.2 implementations were already expected to discard bad packets, so they'll naturally skip over early data. So rather than the text in D.3, I think we just say that you treat a DTLS 1.2 ServerHello as an implicit 0-RTT reject and continue on.
On Wed, Sep 18, 2024 at 4:13 PM David Benjamin <david...@chromium.org> wrote: > Another issue with RFC 9147: when does the client switch from sending > 0-RTT to 1-RTT app data, and when does the server start processing 1-RTT > app data from the client? > > This is less of an open question (I think we match how we already resolved > this for QUIC), but is something we should have written down, so consider > this yet another reason we need rfc9147bis. > > Presumably, the client starts sending 1-RTT data, and stops sending 0-RTT > data, as soon as it has sent out its Finished message. This matches other > handshake flows, and also avoids the calling application getting confused > about continuing to send early data after the handshake is reported as > completed. > > But then that begs the opposite question: does the server install the > 1-RTT read keys before or after it receives client Finished? If before, > it's honestly fine (the AEAD tag does the same thing), but it breaks > assumptions made in TLS analysis. If after, there is an awkward hiccup in > the server's ability to receive data from the client, if the Finished > packet is lost. > > For QUIC, we ended up deciding: > - You do not decrypt 1-RTT records until you've received/sent enough to > finish the handshake. > - There is a head-of-line blocking problem at the transition point. > - Clients can mitigate this by eagerly packing the Finished with their app > data until they get an ACK. > https://www.rfc-editor.org/rfc/rfc9001.html#section-5.7 > > TBH, I doubt anyone will actually do the last one. (We are not currently > planning to implement 0-RTT for DTLS at all, unless it ends up being an > easy extra thing.) But I think this is worth writing down explicitly. The > exact timings of key transitions are much more visible to DTLS and QUIC > than they are to TLS, so I think this is worth being explicit about. > > David >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
