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

Group 0-RTT sections #3879

Merged
merged 5 commits into from Jul 14, 2020
Merged

Group 0-RTT sections #3879

Changes from 3 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
035ab1f
Group 0-RTT sections
martinthomson Jul 9, 2020
6641926
Context, context, context
martinthomson Jul 10, 2020
a55dc7b
Fewer words
martinthomson Jul 13, 2020
a76230e
all info
martinthomson Jul 14, 2020
e2b8922
Rewrap
martinthomson Jul 14, 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
56 changes: 42 additions & 14 deletions draft-ietf-quic-tls.md
View file
Open in desktop
Expand Up @@ -690,23 +690,51 @@ Client SHOULD NOT reuse tickets as that allows entities other than the server
to correlate connections; see Section C.4 of {{!TLS13}}.


## Enabling 0-RTT {#enable-0rtt}
## 0-RTT
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
## 0-RTT
## 0-RTT Handshake Delay


The 0-RTT feature in QUIC allows a client to send application data before the
Copy link
Contributor

Choose a reason for hiding this comment

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

s/The 0-RTT feature/0-RTT handshake delay

Copy link
Member Author

Choose a reason for hiding this comment

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

Sorry, I don't know where "delay" comes into this.

handshake is complete. This is made possible by reusing negotiated parameters
from a previous connection. To enable this, 0-RTT depends on the client
Copy link
Contributor

Choose a reason for hiding this comment

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

This still isn't clear that the reused parameters all come from the same previous connection. How about adding the following to the end of this paragraph or the next:

When a client attempts a 0-RTT connection, the critical parameters it remembers and the TLS session ticket it sends to the server must all have come from the same previous connection.

remembering critical parameters and providing the server with a TLS session
ticket that allows the server to recover the same information.

This information includes parameters that determine TLS state, as governed by
{{!TLS13}}, QUIC transport parameters, the chosen application protocol, and any
information the application protocol might need; see {{app-0rtt}}. This
information determines how 0-RTT packets and their contents are formed.

To ensure that the same information is available to both endpoints, information
martinthomson marked this conversation as resolved.
Show resolved Hide resolved
used to establish 0-RTT comes from the same connection. Endpoints cannot
selectively disregard information that might alter the sending or processing of
0-RTT.

{{!TLS13}} sets a limit of 7 days on the time between the original connection
and any attempt to use 0-RTT. There are other constraints on 0-RTT usage,
notably those caused by the potential exposure to replay attack; see {{replay}}.


### Enabling 0-RTT {#enable-0rtt}

To communicate their willingness to process 0-RTT data, servers send a
NewSessionTicket message that contains the "early_data" extension with a
max_early_data_size of 0xffffffff; the amount of data which the client can send
in 0-RTT is controlled by the "initial_max_data" transport parameter supplied
by the server. Servers MUST NOT send the "early_data" extension with a
max_early_data_size set to any value other than 0xffffffff. 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.
max_early_data_size of 0xffffffff. The TLS max_early_data_size parameter is not
used in QUIC. The amount of data which the client can send in 0-RTT is
controlled by the "initial_max_data" transport parameter supplied by the server.

Servers MUST NOT send the "early_data" extension with a max_early_data_size set
to any value other than 0xffffffff. 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.
the ClientHello message of a subsequent handshake; see Section 4.2.10 of
{{!TLS13}}. It then sends application data in 0-RTT packets.

A client that attempts 0-RTT might also provide an address validation token if
the server has sent a NEW_TOKEN frame; see Section 8.1 of {{QUIC-TRANSPORT}}.


## Accepting and Rejecting 0-RTT
### 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
Expand All @@ -724,11 +752,11 @@ might be incorrect. This includes the choice of application protocol, transport
parameters, and any application configuration. The client therefore MUST reset
the state of all streams, including application state bound to those streams.

A client MAY attempt to send 0-RTT again if it receives a Retry or Version
Negotiation packet. These packets do not signify rejection of 0-RTT.
A client MAY reattempt 0-RTT if it receives a Retry or Version Negotiation
packet. These packets do not signify rejection of 0-RTT.


## Validating 0-RTT Configuration
### Validating 0-RTT Configuration {#app-0rtt}

When a server receives a ClientHello with the "early_data" extension, it has to
decide whether to accept or reject early data from the client. Some of this
Expand Down Expand Up @@ -1742,7 +1770,7 @@ Use of TLS session tickets allows servers and possibly other entities to
correlate connections made by the same client; see {{resumption}} for details.


## Replay Attacks with 0-RTT
## Replay Attacks with 0-RTT {#replay}

As described in Section 8 of {{!TLS13}}, use of TLS early data comes with an
exposure to replay attack. The use of 0-RTT in QUIC is similarly vulnerable to
Expand Down