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

describe how 0-RTT is accepted and rejected #2841

Merged
merged 16 commits into from Aug 16, 2019
Merged

describe how 0-RTT is accepted and rejected #2841

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
1585f08
describe how 0-RTT is accepted and rejected
marten-seemann Jun 24, 2019
de85a4b
s/with/without for rejecting 0-RTT
marten-seemann Jun 25, 2019
94cbd5a
error when 0-RTT is acked when 0-RTT is rejected
marten-seemann Jun 25, 2019
6facb9d
remove normative language for receiving 0-RTT packets
marten-seemann Jun 25, 2019
c0b38a3
add a paragraph describing how a client enables 0-RTT
marten-seemann Jun 25, 2019
a6c47ee
capitalize all words in section title
marten-seemann Jun 25, 2019
9440ab9
s/EarlyDataIndication/early_data extension/g
marten-seemann Jun 25, 2019
5fa9df2
clients SHOULD detect ACKs for 0-RTT packets after 0-RTT rejection
marten-seemann Jun 25, 2019
6ec7024
a client sends 0-RTT packets, not early data
marten-seemann Jun 25, 2019
c9386c4
*an* early_data extension
marten-seemann Jun 26, 2019
32a7bb0
rejecting 0-RTT means not generating 0-RTT keys
marten-seemann Jun 26, 2019
2ddaf6d
apply @kazuho's suggestions
marten-seemann Jun 26, 2019
0400ce1
early_data is sent in the EE, not the SH
marten-seemann Jun 26, 2019
607a9f4
another fix for early_data being sent in EE, not SH
marten-seemann Jun 26, 2019
9c7fa1a
fix reference to RFC 8446
marten-seemann Jun 26, 2019
025b18e
Merge branch 'master' into accept-and-reject-0-rtt
martinthomson Jul 9, 2019
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
23 changes: 19 additions & 4 deletions draft-ietf-quic-tls.md
View file
Open in desktop
Expand Up @@ -613,12 +613,27 @@ by the "initial_max_data" transport parameter supplied by the server. A client
MUST treat receipt of a NewSessionTicket that contains an "early_data" extension
with any other value as a connection error of type PROTOCOL_VIOLATION.

A client that wishes to send 0-RTT packets uses the "early_data" extension in
the ClientHello message of a subsequent handshake (see Section 4.2.10 of
{{!TLS13}}). It then sends the application data in 0-RTT packets.

## Rejecting 0-RTT
Early data within the TLS connection MUST NOT be used. As it is for other TLS
application data, a server MUST treat receiving early data on the TLS connection
marten-seemann marked this conversation as resolved.
Show resolved Hide resolved
as a connection error of type PROTOCOL_VIOLATION.

A server rejects 0-RTT by rejecting 0-RTT at the TLS layer. This also prevents
QUIC from sending 0-RTT data. A server will always reject 0-RTT if it sends a
TLS HelloRetryRequest.

## Accepting and Rejecting 0-RTT

A server accepts 0-RTT by sending an early_data extension in the
EncryptedExtensions (see Section 4.2.10 of {{!TLS13}}). The server then
processes and acknowledges the 0-RTT packets that it receives.

A server rejects 0-RTT by sending the EncryptedExtensions without an early_data
extension. A server will always reject 0-RTT if it sends a TLS
HelloRetryRequest. When rejecting 0-RTT, a server MUST NOT process any 0-RTT
packets, even if it could. When 0-RTT was rejected, a client SHOULD treat
receipt of an acknowledgement for a 0-RTT packet as a connection error of type
marten-seemann marked this conversation as resolved.
Show resolved Hide resolved
PROTOCOL_VIOLATION, if it is able to detect the condition.

When 0-RTT is rejected, all connection characteristics that the client assumed
might be incorrect. This includes the choice of application protocol, transport
Expand Down
6 changes: 6 additions & 0 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -2947,6 +2947,12 @@ to unnecessarily retransmit some data. Standard QUIC algorithms
acknowledged. Therefore, the receiver SHOULD repeatedly acknowledge newly
received packets in preference to packets received in the past.

An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not
send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/for a packet it did not send/for a packet that the server would not have processed/

The change is necessary because 0-RTT packets are sent (but not expected to be processed).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This applies in both directions though. Maybe we shouldn't update the transport doc at all?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad, I think the replacement should be "for a packet that the peer would not have processed".

the condition. This includes receiving an ACK frame containing a packet number
that the endpoint has not sent, as well as acknowledgements for 0-RTT packets
when the server has rejected the use of 0-RTT.


### ACK Frames and Packet Protection

Expand Down