Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
First byte changes #2006
This is a first draft of the changes that we discussed, first in NYC, then confirmed in Bangkok.
I had to recast "packet number protection" as header protection, but I took the opportunity to expand the text and organize it some more. I'm not especially happy with the picture, and could probably drop that, but I think that the changes clarify the process more.
The changes are all exactly as discussed, except that I ended up moving the ODCIL field from the Retry packet, which conveniently fit into four bits that I was struggling to describe what to do with. The low four bits in Retry can't be protected because Retry packets aren't protected. This seemed like a neat way of handling that.
I'm not certain that these are the only changes needed, but I think that this is essentially complete. It's good to get everything nailed down finally.
I am not sure if that is true, because header protection key remains consistent between Key Updates.
Taking these two reserved bits under the crypto umbrella is a strong brake for future (post-v1) experiments in the area of on-path measurement. Indeed, it may be useful to set up asymmetric experiments where only the server puts some path-observable data in these bits (e.g. loss bits), allowing unexpensive, massive field tests with unmodified clients. That's not possible if (1) the bits are encrypted or (2) the client rejects any nonzero value.
Having only one spin bit for in-network measurements make it very hard to identify issues in the network. To do so, you may need loss and latency measurements that can hardly be achieved with a single bit. What is the rationale behind including these bits under the the header protection ?
referenced this pull request
Nov 17, 2018
As noted on #2006 (comment) (sorry for not making it a review comment), I think you need to change the definition of Stateless Reset.
It currently says:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ |0|K|1|1|0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random Bytes (160..) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
IIUC, this needs to be something like below (though, I am not sure if the spin bit needs to be random in this case).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+ |0|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random Bits (166..) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
Suppose that two parties negotiate experimentation with error detection, using either version negotiation or transport parameters. The only requirement would be to set the VEC or ERR bits after packet header protection when sending, and to reset them to zero just before AEAD decryption when receiving. You could specify that as part of the negotiation.