Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove EndOfEarlyData from TLS #1792

Merged
merged 5 commits into from Sep 25, 2018
Merged

Remove EndOfEarlyData from TLS #1792

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
4a58e88
Remove EndOfEarlyData from TLS
martinthomson Sep 24, 2018
5ad418c
CRYPTO can't appear at 0-RTT any more
martinthomson Sep 24, 2018
05f5516
Discarding 0-RTT keys is more complicated now
martinthomson Sep 25, 2018
ace1ee1
Don't allow this with TCP
martinthomson Sep 25, 2018
44bc656
Snafu regarding 0-RTT and handshake interleaving
martinthomson Sep 25, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
15 changes: 8 additions & 7 deletions draft-ietf-quic-tls.md
View file
Open in desktop
Expand Up @@ -655,13 +655,14 @@ all the acknowledgements necessary to reach the same state.

After all CRYPTO frames for a given encryption level have been sent and all
expected CRYPTO frames received, and all the corresponding acknowledgments have
been received or sent, an endpoint starts a timer. To limit the effect of
packet loss around a change in keys, endpoints MUST retain packet protection
keys for that encryption level for at least three times the current
Retransmission Timeout (RTO) interval as defined in {{QUIC-RECOVERY}}.
Retaining keys for this interval allows packets containing CRYPTO or ACK frames
at that encryption level to be sent if packets are determined to be lost or new
packets require acknowledgment.
been received or sent, an endpoint starts a timer. For 0-RTT keys, which do not
carry CRYPTO frames, this timer starts when the first packets protected with
1-RTT are sent or received. To limit the effect of packet loss around a change
in keys, endpoints MUST retain packet protection keys for that encryption level
for at least three times the current Retransmission Timeout (RTO) interval as
defined in {{QUIC-RECOVERY}}. Retaining keys for this interval allows packets
containing CRYPTO or ACK frames at that encryption level to be sent if packets
are determined to be lost or new packets require acknowledgment.

Though an endpoint might retain older keys, new data MUST be sent at the highest
currently-available encryption level. Only ACK frames and retransmissions of
Expand Down