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

Remove initial packet number randomization #850

Closed
janaiyengar opened this issue Oct 10, 2017 · 4 comments
Closed

Remove initial packet number randomization #850

janaiyengar opened this issue Oct 10, 2017 · 4 comments
Assignees
@janaiyengar
Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@janaiyengar
Copy link
Contributor

With the resolution of #693 we no longer need initial packet numbers to be randomized.
@janaiyengar janaiyengar added -transport design An issue that affects the design of the protocol; resolution requires consensus. labels Oct 10, 2017
@janaiyengar janaiyengar self-assigned this Oct 10, 2017
mcmanus added a commit to mcmanus/base-drafts that referenced this issue Oct 12, 2017
@mcmanus
intial packet number should be 0.
0e54993 
Closes quicwg#850
@mcmanus mcmanus mentioned this issue Oct 12, 2017
Closed
@mcmanus
Copy link
Contributor

mcmanus commented Oct 12, 2017

my PR for this conflicted with #824 so I made the PR be for that branch and it can close both issues (this and #823) if accepted.

@martinthomson martinthomson mentioned this issue Oct 13, 2017
Merged
@martinthomson martinthomson added this to Handshake in QUIC Nov 7, 2017
@marten-seemann
Copy link
Contributor

After some discussion at the Singapore Hackathon: The reason why #693 solves this, is because the client-chosen connection ID is used for the AEAD. This also applies in the case where the server directly replies with a Cleartext and uses a server-chosen connection ID.

@janaiyengar
Copy link
Contributor Author

On whether initial packet number should be 0 or 1, with the new packet number encoding, we end up needing only 62 bis for the packet number, which means you can use a signed int for representing it and < 0 as a sentinel value. I'll be ok with either 0 or 1 as the initial value.

@ianswett
Copy link
Contributor

Q on this. Should we allow using other initial packet numbers to make sure middleboxes don't assume all handshake packets are <20 or some magic number?

Admittedly, the type byte is a lot more useful than packet number to identify handshake packets, but it's worth considering.

Besides that, I'm greatly in favor of this and would like it to land ASAP.

martinthomson added a commit that referenced this issue Nov 29, 2017
@martinthomson
Randomize packet numbers more, not less
7f47639 
Closes #864, #850.
martinthomson added a commit that referenced this issue Nov 29, 2017
@martinthomson
Randomize packet numbers more, not less
d2379eb 
Closes #864, #850.
@martinthomson martinthomson mentioned this issue Nov 29, 2017
Merged
janaiyengar pushed a commit that referenced this issue Nov 30, 2017
@martinthomson
Randomize packet numbers more, not less (#964)
973c6dd 
* Randomize packet numbers more, not less

Closes #864, #850.

* More precisely define the range (not that it matters)

* Remove sentence about encodings
martinthomson added a commit that referenced this issue Jan 9, 2018
@martinthomson
Mask packet numbers with a per-connection-ID key
7956578 
This changes the key schedule so that connection ID is part of the key
derivation.  Secrets are generally unchanged, except that the handshake secret
is now fixed (we integrate the connection ID via key derivation).

Packet numbers now start from zero, with an additive masking value that is
derived in the same way that packet protection keys are.

Closes #1034, #850.
@martinthomson martinthomson mentioned this issue Jan 9, 2018
Closed
martinthomson added a commit that referenced this issue Jan 15, 2018
@martinthomson
Mike's editorial comments
483a59d 
Closes #1048, #1034, #850, #990, #311.
@martinthomson martinthomson mentioned this issue Jan 29, 2018
Merged
@mnot mnot removed this from Handshake in QUIC Mar 15, 2018
@mnot mnot added has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. and removed has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. labels Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@janaiyengar janaiyengar

Labels
-transport design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@mnot @mcmanus @marten-seemann @janaiyengar @ianswett