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

From: MikkelFJ <[email-masked]>
Date: Thu, 01 Nov 2018 01:31:49 -0700

QUIC is useful for all sorts of custom data sync protocols that curtently use TCP+TLS.

-- 
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-434970089

---

From: Marten Seemann <[email-masked]>
Date: Thu, 01 Nov 2018 02:59:27 -0700

@DavidSchinazi Every endpoints announces a list of addresses it believes it is reachable at. We currently don't encode the QUIC version number into that address. I'd prefer to not do that, but instead have an efficient QUIC version negotiation mechanism take care of selecting the best version.

-- 
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-434991328

---

From: Nick Banks <[email-masked]>
Date: Thu, 01 Nov 2018 15:47:57 +0000 (UTC)

Microsoft also has a number of other non-HTTP projects under way using QUIC that I think would benefit from this.

-- 
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-435079380

---

From: David Schinazi <[email-masked]>
Date: Thu, 01 Nov 2018 09:54:32 -0700

@mikkelfj I agree that this is definitely useful. The only question I'm asking is which document this should land in and when.
@nibanks, can you comment on which use-case you would benefit from? (draft-to-RFC or v1-to-v2?)

-- 
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-435103710

---

From: Nick Banks <[email-masked]>
Date: Thu, 01 Nov 2018 10:08:54 -0700

@DavidSchinazi possibly both. We will likely have limited deployment of some of the projects before QUIC hits RFC status and we may end up using a draft version number for those. Beyond that, since those protocols won't necessarily have an alt-svc design, the v1-to-v2 would likely be beneficial as well.

-- 
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-435108651

---

From: martinduke <[email-masked]>
Date: Thu, 01 Nov 2018 20:04:46 -0700

Can we land the bit where we add supported-versions to client TPs and argue about seamless upgrade in Bangkok?

-- 
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-435256816

---

From: David Schinazi <[email-masked]>
Date: Thu, 01 Nov 2018 20:34:44 -0700

@martinduke +1

-- 
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-435260997

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 01 Nov 2018 20:41:35 -0700

In my view, one of the potential issues regarding the current design of "compatible version upgrade" is that it states that the server "MAY" upgrade, while not giving the client a way to opt out.

Would it help the people not interested in implementing compatible version upgrade if the feature was made optional from the client's viewpoint?

-- 
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-435261937

---

From: MikkelFJ <[email-masked]>
Date: Fri, 02 Nov 2018 00:38:00 -0700

@kazuho I think the objection has more to do with interop and unforeseen cornercases and vulnerabilities than it has to do with ones own implementation.

-- 
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-435296059

---

From: martinduke <[email-masked]>
Date: Sun, 04 Nov 2018 23:08:06 -0800

After discussing this with @kazuho, @janaiyengar, and @ianswett in Bangkok, I'm not sure the server upgrade problem has been correctly reasoned.

Downgrade attack detection happens in the context of a single connection. After receiving VN, the client uses the same CID and increments the packet number. Non-pathological load balancers will direct this to the same server. People have repeatedly pointed out to me that the LB config could flip over in that moment, but that is an edge case of an edge case, and the only consequence is a fatal connection error and a possible security alert.

It might we worth adding somewhere that in the event of a downgrade alert, the client SHOULD NOT cache the contents of VN for future use. Also, if the server's TPs don't match the contents of a client version cache from a different connection, that is not a downgrade attack.

Furthermore, @ianswett points out that downgrade attack detection traditionally happens at the client. We haven't fully thought through the incentives and other implications of moving this responsibility to the server.

In summary, I no longer support moving downgrade detection to the server.  I am open to seamless upgrade in v2 after we do some more analysis to make sure there are no gotchas.

-- 
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-435774516

---

From: martinduke <[email-masked]>
Date: Tue, 06 Nov 2018 21:07:51 -0800

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.

-- 
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-436506418

---

From: MikkelFJ <[email-masked]>
Date: Wed, 07 Nov 2018 00:03:41 -0800

I must admit I don’t quite follow why min DCID is important.

Regardless, forcing a higher min DCID is unfortunate because a system that relies on small DCIDs in its default operational mode will be forced to not support other versions with larger DCIDs.

-- 
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-436537460

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 07 Nov 2018 00:28:51 -0800

> 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…

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

---

From: Igor Lubashev <[email-masked]>
Date: Wed, 07 Nov 2018 00:44:30 -0800

> 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…

@martinduke, I think it is not only an issue with max DCID but also min DCID.  The client MUST select an initial DCID whose length falls within the range of valid DCID lengths for each version it supports.  What this means is that if versions A and B require DCIDs to be between (Xa and Ya) and (Xb and Yb) long respectively, Xa-Ya and Xb-Yb ranges would better overlap, or no client would be able to support both A and B.

The Invariants could specify the largest-allowed-min and smallest-allowed-max DCID lengths.  But it is also possible to leave the matter to future version specs, which would need to take care of ensuring an overlap in DCID length with all prior versions they wish to "co-exist" with.

-- 
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-436547896

---

From: martinduke <[email-masked]>
Date: Wed, 07 Nov 2018 00:49:00 -0800

@igorlord I agree, although I cannot see a use case that would really require an upper limit on initial DCID len. So I think it is simpler just to hold the max length constant and allow versions to vary min length (as this value is needed to provide minimum entropy for Retry and VN packets).

-- 
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-436549074

---

From: MikkelFJ <[email-masked]>
Date: Wed, 07 Nov 2018 01:29:17 -0800

How about separating VN / Retry entropy from DCID lengths if this is the only thing that blocks short DCIDs from coexisting with "standard" DCID min lengths?

-- 
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-436560520

---

From: martinduke <[email-masked]>
Date: Wed, 07 Nov 2018 01:33:05 -0800

How would you do that? This is only relevant to the Initial DCID, not the server-proposed one.

-- 
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-436561691

---

From: MikkelFJ <[email-masked]>
Date: Wed, 07 Nov 2018 01:41:07 -0800

If the version dependent DCID length really only is a concern for the intial packet, then I suggest that this length is hardcoded to 128-bits, independent of SCID/DCID length requirements of any given version.

-- 
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-436564111

---

From: MikkelFJ <[email-masked]>
Date: Wed, 07 Nov 2018 09:43:05 +0000 (UTC)

Note that the initial DCID is expected to be random and not contain any load balancer coordination etc.

-- 
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-436564690

---

From: Martin Thomson <[email-masked]>
Date: Wed, 07 Nov 2018 17:12:32 -0800

After talking to several people, I think that we will close this PR for now while we consider our options.

Note that @kazuho's [suggested design](https://github.com/quicwg/base-drafts/pull/1901#issuecomment-436543850) isn't perfect.  It still has a problem around the transition from step 2 to 3.

-- 
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-436837056

---

From: Martin Thomson <[email-masked]>
Date: Wed, 07 Nov 2018 17:12:35 -0800

Closed #1901.

-- 
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#event-1953143726