feat[tokio-quiche]: implement server-side support for 0-RTT#2267
Merged
feat[tokio-quiche]: implement server-side support for 0-RTT#2267
Conversation
toidiu
changed the title
toidiu
commented
Dec 5, 2025
toidiu
commented
Dec 5, 2025
toidiu
commented
Dec 5, 2025
toidiu
force-pushed
the
akothari/0-rtt
branch
7 times, most recently
from
c0a7cad to
f5b3c4e
Compare
toidiu
commented
Dec 8, 2025
LPardue
reviewed
Dec 8, 2025
LPardue
reviewed
Dec 8, 2025
toidiu
force-pushed
the
akothari/0-rtt
branch
2 times, most recently
from
5a15fee to
2635dff
Compare
toidiu
changed the title
toidiu
force-pushed
the
akothari/0-rtt
branch
from
2635dff to
95b6031
Compare
toidiu
changed the title
toidiu
force-pushed
the
akothari/0-rtt
branch
from
95b6031 to
e577935
Compare
jannes
reviewed
Dec 9, 2025
jannes
reviewed
Dec 9, 2025
toidiu
force-pushed
the
akothari/0-rtt
branch
from
e577935 to
280f94a
Compare
toidiu
force-pushed
the
akothari/0-rtt
branch
from
280f94a to
3905c05
Compare
Contributor
Author
|
@evanrittenhouse 👏 helped confirm that we want to record the handshake duration as soon as we resume the early connection. @evanrittenhouse and I discovered that we set the handshake duration right after resumption with 0-rtt. Wondering if this is ok or if we want to record the duration when the full handshake finishes. https://github.com/cloudflare/quiche/blob/master/tokio-quiche/src/quic/io/worker.rs#L787-L788 |
toidiu
force-pushed
the
akothari/0-rtt
branch
3 times, most recently
from
942bee3 to
41d6be1
Compare
toidiu
force-pushed
the
akothari/0-rtt
branch
2 times, most recently
from
f5e8687 to
f1ccd06
Compare
evanrittenhouse
approved these changes
Jan 12, 2026
ghedo
approved these changes
Jan 15, 2026
Member
|
Looks like there is a conflicts with one of the other changes now 😿 |
This PR adds a setting to enable 0-RTT resumption and early data processing for the server. Early data uses 0-RTT keys, which are established from a previous session data (aka. session resumption). The most obvious downside of this is the ability for an attacker to replay a request to the server. Application therefore need to be careful when enabling 0-RTT and processing early data requests. For more information see BoringSSL docs: https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#Early-data
toidiu
force-pushed
the
akothari/0-rtt
branch
from
6df8bd8 to
41ec0b8
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds server support for 0-RTT. This is done by transitioning the Handshake to Application when we have 0-RTT keys. The PR also adds an extension header IsInEarlyData to forward the early data request status so application can detect when a request was received with 0-RTT keys (and take appropriate security precautions).