Re: [quicwg/base-drafts] [Version Ossification] Alternative version and Initial Salt should be part of NEW_TOKEN (#3111)

[Kazuho Oku <[e-mail]>]

@ianswett 
> To clarify what you're getting from this that isn't achieved in TPs is that here you're guaranteed that when the client comes back with the version and salt, they'll also specify the Token. But if these were in transport params, then the client might decide not to send the subsequently transmitted token with the version and salt or the corresponding token might not get delivered in time?

That's correct.

Unless we require the token and the alternative salt to be used together, the only source that we could use to determine the initial salt would be the version number field. That means that there can be at most 2<sup>32</sup> salts, therefore we'd see a birthday problem once we handle 2<sup>16</sup> connections. That's more than enough for ossification, but not as a way to encrypt Initial packets.

If we bundle the token and the alternative salt, and require them to be used together, then the value space of the alternative salt becomes 2<sup>128</sup> that can be unique to each connection.

Note also that being possible to deduct the alternative salt from the NEW_TOKEN tokens simplifies the deployment, because servers dealing with NEW_TOKEN tokens are expected to have a way to deduce other information from the token. The complexity becomes to just adding one more information (which is the alternative salt) to that set of information, whereas we'd be required to retain a map (or define a way to a map) that lists the alternative version numbers and salts, if we do not require the token and the alternative salt to be used together.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3111#issuecomment-544787363