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

multiple editorial nits in Section 7 (Cryptographic and Transport Handshake) #4113

Merged
merged 4 commits into from Sep 22, 2020
Merged

multiple editorial nits in Section 7 (Cryptographic and Transport Handshake) #4113

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
0c23558
remove superfluous paragraph repeating TP validation
marten-seemann Sep 21, 2020
d9622c0
fix incomprehensible sentence about rejecting 0-RTT
marten-seemann Sep 21, 2020
2474054
only require storing of TPs that can be processed
marten-seemann Sep 21, 2020
07832a0
apply @martinthomson's suggestions
marten-seemann Sep 22, 2020
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
17 changes: 7 additions & 10 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -1710,10 +1710,6 @@ When the handshake includes a Retry ({{fig-auth-cid-retry}}), the server sets
original_destination_connection_id to `S1`, retry_source_connection_id to `S2`,
and initial_source_connection_id to `S3`.

Each endpoint validates transport parameters set by the peer. The client
confirms that the retry_source_connection_id transport parameter is absent if it
did not process a Retry packet.


## Transport Parameters {#transport-parameters}

Expand Down Expand Up @@ -1784,10 +1780,11 @@ server's new values in the handshake instead; if the server does not provide new
values, the default value is used.

A client that attempts to send 0-RTT data MUST remember all other transport
parameters used by the server. The server can remember these transport
parameters, or store an integrity-protected copy of the values in the ticket
and recover the information when accepting 0-RTT data. A server uses the
transport parameters in determining whether to accept 0-RTT data.
parameters used by the server that it is able to process. The server can
remember these transport parameters, or store an integrity-protected copy of
the values in the ticket and recover the information when accepting 0-RTT data.
A server uses the transport parameters in determining whether to accept 0-RTT
data.

If 0-RTT data is accepted by the server, the server MUST NOT reduce any
limits or alter any values that might be violated by the client with its
Expand Down Expand Up @@ -1818,8 +1815,8 @@ connection. Specifically, lowering the max_udp_payload_size could result in
dropped packets leading to worse performance compared to rejecting 0-RTT data
outright.

A server MUST either reject 0-RTT data or abort a handshake if the implied
values for transport parameters cannot be supported.
A server MUST reject 0-RTT data if the restored values for transport
parameters cannot be supported.

When sending frames in 0-RTT packets, a client MUST only use remembered
transport parameters; importantly, it MUST NOT use updated values that it learns
Expand Down