Re: [quicwg/base-drafts] Compatible version upgrade (#1901)

[Kazuho Oku <[e-mail]>]

@martinduke:
> In Bangkok @kazuho short-circuited my objection at the mic by pointing out that the min DCID length might be different in other versions.
> 
> Upon further review, this requires a minor tweak to the spec: the client MUST select an initial DCID long enough for every version it supports. This implies that the maximum initial DCID length is invariant across versions, but I can't see a use case where we would drop that below 18.

FWIW, let me note that in the current design, it is not impossible for a server cluster with mixed supported versions to respond in a way that does not cause the clients to see "downgrade attacks", even in case the resent Initial lands on a different server within the cluster.

This is how you would do in case you are upgrading a cluster to support v2:

1. Some of the servers start accepting v2, but continues to claim support only for v1 in the VN packets.
2. During this period, when the server receives a v1 Initial, it responds with `supported_versions` that only contains v1. When the server receives a v2 Initial, it responds with `supported_versions` that contains both v1 and v2.
3. After all servers start accepting v2, they start sending v2 in the VN packet and also in `supported_versions`.

The difference from what you would do when we have "compatible version upgrade" is step 2; we need to send different `supported_versions` based on the version number of the client's Initial. This looks strange, but I think it would work.

-- 
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/pull/1901#issuecomment-436543850