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.
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
Group 0-RTT sections #3879
Group 0-RTT sections #3879
Conversation
This adds a short introductory section to the three sections that deal with 0-RTT. That might help contextualize and help contain the spaghetti structure that this section seems to have.
Just a little more context and a reference to the TLS spec. Note that this somewhat assumes that #3879 will proceed, as this gives a pointer to a single section, rather than three.
|
||
The 0-RTT feature in QUIC allows a client to send application data before the | ||
handshake is complete. This is made possible by reusing negotiated parameters | ||
from a previous connection. To enable this, 0-RTT depends on the client |
There was a problem hiding this comment.
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.
Thanks Nick. I took it in a slightly different direction, but I think that I captured this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change looks good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One high-order bit: Using 0-RTT as a noun doesn't sound right, though we do use it informally in that sense. My suggestion use of "The 0-RTT handshake delay feature" or "0-RTT delay before sending application data" as appropriate.
@@ -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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## 0-RTT | |
## 0-RTT Handshake Delay |
## Enabling 0-RTT {#enable-0rtt} | ||
## 0-RTT | ||
|
||
The 0-RTT feature in QUIC allows a client to send application data before the |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
draft-ietf-quic-tls.md
Outdated
To ensure that the same information is available to both endpoints, information | ||
used to establish 0-RTT comes from the same connection and all information that | ||
might affect 0-RTT is retained. Endpoints cannot selectively disregard |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rephrase this sentence -- I'm having a hard time parsing it.
This adds a short introductory section to the three sections that deal
with 0-RTT. That might help contextualize and help contain the
spaghetti structure that this section seems to have.