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.

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

Make error codes smaller #723

Closed
wants to merge 59 commits into from
Closed

Make error codes smaller #723

wants to merge 59 commits into from

Conversation

martinthomson
Copy link
Member

With #722, the error code space is much more tightly defined. We don't need the enormous space that we have. A 16-bit value is adequate.

Copy link
Contributor

@janaiyengar janaiyengar left a comment

Choose a reason for hiding this comment

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

LGTM -- this seems sane. 64K ought to be enough for anybody! (TM)

@MikeBishop
Copy link
Contributor

LGTM. I did the conflict resolution just to keep our PRs clean.

@mnot mnot removed the design An issue that affects the design of the protocol; resolution requires consensus. label Sep 25, 2017
ekr and others added 10 commits October 2, 2017 15:22
Clarify the first flight, explicitly excluding NST
* Split error code space

This creates two orthogonal spaces for error codes.  Application error codes
can be used for both connection and stream errors and are under the control of
the application protocol.  Transport error codes are QUIC-controlled, but can
only terminate the connection.

To fix this, I had to add IANA considerations for error codes, plus a few extra
tweaks.  I think that the error code space could be narrowed to 16 bits after
this, if only to keep things sane.

Closes #132.

* s/Public Reset/Stateless Reset/

* Get codes consistent

* Make STOP_SENDING application-specific as well

* Split errors in HTTP too

* Refine description of HTTP codes

* Move TLS errors closer

* Match the names

* Add HTTP_NO_ERROR

* Review comments

* Jana's comments

* Small tweak at Mike's suggestion

* Reword STOP_SENDING text to avoid implication of mandatory RST_STREAM

* Better track changes on master

* Reword advice on application error codes

* Steal a code from the application

* Simply reserve the RST_STREAM code of 0.

* Application error code missed

* We really should just call this STOPPING
ianswett and others added 15 commits October 5, 2017 23:41
This makes the change we discussed in Seattle where all Cleartext
packets are encrypted with AES-GCM using a key derived from the
client connection ID and a random per-version value.

Note: I generated this value using randomness.org.
the revision corresponding to the -06 drafts. It's still essentially
arbitrary but now it's predictable arbitrary.
The change in #844 didn't mention the hash function used with HKDF.  It is
pretty obviously SHA-256, but we need to write that down.

Also a few editorial changes.
Followup for cleartext AEAD change
Otherwise, version negotiation doesn't work.
Don't retransmit old MAX_STREAM_DATA and MAX_DATA
  * error codes can be used with stop_sending
@martinthomson
Copy link
Member Author

Ahh, I see the problem now. @janaiyengar I will create a new PR for this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants