Subject: QUIC ossification

From: Martin Duke <[email-masked]>
Date: Tue, 12 Feb 2019 13:18:55 -0800

Mark's last call for design issues led me to think about ossification
issues. We have done just about everything we can to prevent ossification.
There's a thread elsewhere about the QUIC bit, but beyond that I see two
big concerns.

1) Version. I can't think of any immediate negative consequences for a
middlebox that drops any long header with a version > 1. TLS 1.3 had to
surrender to this problem by hiding the version elsewhere.

We might avoid this by routinely coalescing long headers with random
version fields to connection-critical packets. Beyond that, I'm out of
great ideas. If we don't have a robust defense against this, we ought to
put some thought into how to deploy a v2 if the version fields is
inoperable.

2) Client Transport Parameters. Initial Keys will help a little bit, but in
TLS1.3 CCS still sorta exists because middleboxes are inspecting packets so
deeply. It's not viable for v2 to have the same transport parameters; it's
only slightly less gross to send v2 client TPs in some later message and
have to send a fairly bulky "fake" set of v1 TPs in the client hello to get
through the network.

I don't have great solutions to either of these, but I think these are
issues worth discussing given the effort we've put into blocking
ossification. If we can't adequately punish misbehaving middleboxes via
greasing-like behaviors, then we should at least have contingency plans if
the ossifiable fields do, in fact, ossify.

If this is a fruitful discussion area, I'm happy to file a github issue.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Feb 2019 08:35:32 +1100

> put some thought into how to deploy a v2 if the version fields is

As Mike points out, the Length field is version-specific, so there is no real defense here other than - as many have suggested - using the version field actively.  That means shipping another version.  In a sense, the fact that Google are still not on the same version gives us some time, but it could mean that we might want to look toward having the "add version negotiation and fallback protection" draft define a version rather than an extension.
 
> have to send a fairly bulky "fake" set of v1 TPs in the client hello to get

I'm not concerned about transport parameters if the above issue is fixed.  TLS had no real issues with extensions, and it looks like we already have the start of a pipeline of extensions coming.  v2 can share the transport parameter extension, unless we decide to change the format in a non-compatible way.

(Note: CCS in TLS 1.3 only exists because middleboxes were inspecting a lot, yes, but it also indicates that they weren't inspecting enough, because the compatibility hack we have wouldn't work if they did a proper job.)

---

From: Roberto Peon <[email-masked]>
Date: Tue, 12 Feb 2019 22:14:25 +0000

My fear/experience around this is why I'd strongly recommend doing a QUIC V2 as soon as possible where the delta from V1 -> V2 is limited to *solely* what is necessary for version negotiation. 

We can simultaneously have a V3 conversation which would  include whatever else we decide we need to change/add as a separate conversation which depends on V2.

-=R

On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: David Schinazi <[email-masked]>
Date: Tue, 12 Feb 2019 16:13:08 -0800

I think we may be able to limit ossification of version numbers by adding
some GREASE to the (upcoming) in-band compatible version upgrade extension
(what used to be EKR's PR). The idea of that extension is that the client
sends a QUICv1 initial containing a transport parameter indicating it
supports this extension and what versions of QUIC it supports. The server
can then send its replies with a new QUIC version number. Back to GREASE:
one option here would be for us to burn some versions for "v1 compatible
version negotiation greasing" (similar but different to 0x?a?a?a?a) and
servers can in-band upgrade to those versions. But we could also do that in
the reverse direction: the servers advertise support for one of these in
Alt-Svc and clients send their Initial to that version, and the server can
then perform in-band version change to v1, to another of these versions, or
just keep the client's version for the life of this connection. This will
cause ossifying middleboxes to break these connections.

Thoughts?

David

On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon <[email-masked]> wrote:

> My fear/experience around this is why I'd strongly recommend doing a QUIC
> V2 as soon as possible where the delta from V1 -> V2 is limited to *solely*
> what is necessary for version negotiation.
>
> We can simultaneously have a V3 conversation which would  include whatever
> else we decide we need to change/add as a separate conversation which
> depends on V2.
>
> -=R
>
> On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     As Mike points out, the Length field is version-specific, so there is
> no real defense here other than - as many have suggested - using the
> version field actively.  That means shipping another version.  In a sense,
> the fact that Google are still not on the same version gives us some time,
> but it could mean that we might want to look toward having the "add version
> negotiation and fallback protection" draft define a version rather than an
> extension.
>
>     I'm not concerned about transport parameters if the above issue is
> fixed.  TLS had no real issues with extensions, and it looks like we
> already have the start of a pipeline of extensions coming.  v2 can share
> the transport parameter extension, unless we decide to change the format in
> a non-compatible way.
>
>     (Note: CCS in TLS 1.3 only exists because middleboxes were inspecting
> a lot, yes, but it also indicates that they weren't inspecting enough,
> because the compatibility hack we have wouldn't work if they did a proper
> job.)
>
>
>
>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 13 Feb 2019 00:20:52 +0000

I don’t have an opinion on how version is negotiated yet.
I’m not convinced it is easy to get right. It may be more correct for me to say that I’m convinced it is reasonable difficult to get right because it is the most important of the various invariants.

I also suspect that you need more than one way to do it, e.g. in-band and out-of-band (which could be in-band in a V2 to allow for upgrade to something else). Then does a client cache the version? For how long/where? Per IP? Hostname? (blah blah.. etc. etc.)

I can say that the ALPN and NPN approaches each had their positives and negatives, and in the end, having something like either is probably good enough.

Rather than an opinion on how it should be done, I have an opinion that we need to add this soon, as a V2.

-=R

From: David Schinazi <[email-masked]>
Date: Tuesday, February 12, 2019 at 4:13 PM
To: Roberto Peon <[email-masked]>
Cc: Martin Thomson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: QUIC ossification

I think we may be able to limit ossification of version numbers by adding some GREASE to the (upcoming) in-band compatible version upgrade extension (what used to be EKR's PR). The idea of that extension is that the client sends a QUICv1 initial containing a transport parameter indicating it supports this extension and what versions of QUIC it supports. The server can then send its replies with a new QUIC version number. Back to GREASE: one option here would be for us to burn some versions for "v1 compatible version negotiation greasing" (similar but different to 0x?a?a?a?a) and servers can in-band upgrade to those versions. But we could also do that in the reverse direction: the servers advertise support for one of these in Alt-Svc and clients send their Initial to that version, and the server can then perform in-band version change to v1, to another of these versions, or just keep the client's version for the life of this connection. This will cause ossifying middleboxes to break these connections.

Thoughts?

David

On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:
My fear/experience around this is why I'd strongly recommend doing a QUIC V2 as soon as possible where the delta from V1 -> V2 is limited to *solely* what is necessary for version negotiation.

-=R

On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

---

From: Martin Duke <[email-masked]>
Date: Wed, 13 Feb 2019 08:17:07 -0800

I agree that a fast v2 would help here. However, it's hard to count on a
fast IETF process, and even then the middlebox can be pretty dumb and still
drop version > 2.

I agree that David's scheme, by having the Initial be a v1 packet, may get
that one through. But then you have subsequent long headers with the new
version, which may still end badly.

I don't see a good solution here, right now. Although it shouldn't be
written in the spec, the working group should have some sort of contingency
plan for how to proceed if the version field ossifies.

On Tue, Feb 12, 2019 at 4:21 PM Roberto Peon <[email-masked]> wrote:

> I’m not convinced it is easy to get right. It may be more correct for me
> to say that I’m convinced it is reasonable difficult to get right because
> it is the most important of the various invariants.
>
> I also suspect that you need more than one way to do it, e.g. in-band and
> out-of-band (which could be in-band in a V2 to allow for upgrade to
> something else). Then does a client cache the version? For how long/where?
> Per IP? Hostname? (blah blah.. etc. etc.)
>
> I can say that the ALPN and NPN approaches each had their positives and
> negatives, and in the end, having something like either is probably good
> enough.
>
> *From: *David Schinazi <[email-masked]>
> *Date: *Tuesday, February 12, 2019 at 4:13 PM
> *To: *Roberto Peon <[email-masked]>
> *Cc: *Martin Thomson <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: QUIC ossification
>
>
>

---

From: Ian Swett <[email-masked]>
Date: Wed, 13 Feb 2019 11:56:11 -0500

Previously David Benjamin suggested spinning a new version of QUIC in
Chrome for every Chrome milestone with the only change being the version
number and the Initial keys.  I'd be curious how the WG feels about that
idea?

On Wed, Feb 13, 2019 at 11:17 AM Martin Duke <[email-masked]>
wrote:

>> We can simultaneously have a V3 conversation which would  include
>> whatever else we decide we need to change/add as a separate conversation
>> which depends on V2.
>>
>> -=R
>>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 13 Feb 2019 09:14:00 -0800

There is the risk that middle boxes learn that versions mean nothing, and
that they are all the same, akin to crying wolf.

If it also mutated transport parameters and other observables, it would
start being a defence.

Alas, once 1.0 hits, things are back to normal.
So I doubt this exercise would be worthwhile.

But, I don’t have any strong opinion.

On 13 February 2019 at 17.56.47, Ian Swett (
ianswett=[email-masked]) wrote:

On Wed, Feb 13, 2019 at 11:17 AM Martin Duke <[email-masked]>
wrote:

>> *From:* David Schinazi <[email-masked]>
>> *Date:* Tuesday, February 12, 2019 at 4:13 PM
>> *To:* Roberto Peon <[email-masked]>
>> *Cc:* Martin Thomson <[email-masked]>, "[email-masked]" <[email-masked]>
>> *Subject:* Re: QUIC ossification
>>
>>
>>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 Feb 2019 09:17:01 -0800

On Wed, Feb 13, 2019 at 9:14 AM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> I tend to agree with this. Version numbers should shift when the
interoperability among parties to the protocol shifts.  While you can
artificially create that shift in closed system, teaching the ecosystem
that the shifts are meaningless doesn't seem to advance the general goal.

Ted

>> I agree that David's scheme, by having the Initial be a v1 packet, may
>> get that one through. But then you have subsequent long headers with the
>> new version, which may still end badly.
>>
>> On Tue, Feb 12, 2019 at 4:21 PM Roberto Peon <fenix@fb..com
>> <[email-masked]>> wrote:
>>
>>> I also suspect that you need more than one way to do it, e.g. in-band
>>> and out-of-band (which could be in-band in a V2 to allow for upgrade to
>>> *Cc:* Martin Thomson <[email-masked]>, "[email-masked]" <[email-masked]
>>> >
>>> I think we may be able to limit ossification of version numbers by
>>> adding some GREASE to the (upcoming) in-band compatible version upgrade
>>> extension (what used to be EKR's PR). The idea of that extension is that
>>> the client sends a QUICv1 initial containing a transport parameter
>>> indicating it supports this extension and what versions of QUIC it
>>> supports. The server can then send its replies with a new QUIC version
>>> number. Back to GREASE: one option here would be for us to burn some
>>> versions for "v1 compatible version negotiation greasing" (similar but
>>> different to 0x?a?a?a?a) and servers can in-band upgrade to those versions.
>>> But we could also do that in the reverse direction: the servers advertise
>>> support for one of these in Alt-Svc and clients send their Initial to that
>>> version, and the server can then perform in-band version change to v1, to
>>> another of these versions, or just keep the client's version for the life
>>> of this connection. This will cause ossifying middleboxes to break these
>>> connections.
>>>
>>>
>>>
>>> Thoughts?
>>>
>>>
>>>
>>> David
>>>
>>>
>>>
>>> My fear/experience around this is why I'd strongly recommend doing a
>>> QUIC V2 as soon as possible where the delta from V1 -> V2 is limited to
>>> *solely* what is necessary for version negotiation.
>>>
>>>     As Mike points out, the Length field is version-specific, so there
>>> is no real defense here other than - as many have suggested - using the
>>>     (Note: CCS in TLS 1.3 only exists because middleboxes were
>>> inspecting a lot, yes, but it also indicates that they weren't inspecting
>>> enough, because the compatibility hack we have wouldn't work if they did a
>>> proper job.)
>>>
>>>
>>>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 13 Feb 2019 07:28:11 -1000

How about an IANA registry of version numbers, tied to the extension process?

-- Christian Huitema 

> On Feb 13, 2019, at 7:17 AM, Ted Hardie <[email-masked]> wrote:
> 
>> On Wed, Feb 13, 2019 at 9:14 AM Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
> 
>> There is the risk that middle boxes learn that versions mean nothing, and that they are all the same, akin to crying wolf.
>> 
> I tend to agree with this. Version numbers should shift when the interoperability among parties to the protocol shifts.  While you can artificially create that shift in closed system, teaching the ecosystem that the shifts are meaningless doesn't seem to advance the general goal.
> 
> Ted
> 
>  
>> If it also mutated transport parameters and other observables, it would start being a defence.
>> 
>>> On 13 February 2019 at 17.56.47, Ian Swett (ianswett=[email-masked]) wrote:
>>> 
>>> Previously David Benjamin suggested spinning a new version of QUIC in Chrome for every Chrome milestone with the only change being the version number and the Initial keys.  I'd be curious how the WG feels about that idea?
>>> 
>>>> On Wed, Feb 13, 2019 at 11:17 AM Martin Duke <[email-masked]> wrote:
>>>> I agree that a fast v2 would help here. However, it's hard to count on a fast IETF process, and even then the middlebox can be pretty dumb and still drop version > 2.
>>>> 
>>>> I agree that David's scheme, by having the Initial be a v1 packet, may get that one through. But then you have subsequent long headers with the new version, which may still end badly.
>>>> 
>>>> I don't see a good solution here, right now. Although it shouldn't be written in the spec, the working group should have some sort of contingency plan for how to proceed if the version field ossifies.
>>>> 
>>>>> On Tue, Feb 12, 2019 at 4:21 PM Roberto Peon <fenix@fb...com> wrote:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 13 Feb 2019 12:02:22 -0600

Hi, Christian,

> How about an IANA registry of version numbers, tied to the extension

Asking as an individual - ISTM that QUIC might go through version numbers
quickly enough to make a registry for version numbers a Good Thing, but
could you help me understand how this helps discourage middleboxes blocking
everything but QUICv1?

I'm sure I'm missing something here ...

Thanks,

Spencer

---

From: Roberto Peon <[email-masked]>
Date: Wed, 13 Feb 2019 21:52:46 +0000

Better that they have to explicitly block than they accidentally block?
Reminder: This applies only to network-visible negotiations.
-=R

From: QUIC <[email-masked]> on behalf of Spencer Dawkins at IETF <[email-masked]>
Date: Wednesday, February 13, 2019 at 10:03 AM
To: Christian Huitema <[email-masked]>
Cc: Ted Hardie <[email-masked]>, Roberto Peon <[email-masked]>, David Benjamin <[email-masked]>, Martin Thomson <[email-masked]>, Ian Swett <ianswett=[email-masked]>, David Schinazi <[email-masked]>, Mikkel Fahnøe Jørgensen <[email-masked]>, "[email-masked]" <[email-masked]>, Martin Duke <[email-masked]>
Subject: Re: QUIC ossification

Hi, Christian,

On Wed, Feb 13, 2019 at 11:28 AM Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:
How about an IANA registry of version numbers, tied to the extension process?

Asking as an individual - ISTM that QUIC might go through version numbers quickly enough to make a registry for version numbers a Good Thing, but could you help me understand how this helps discourage middleboxes blocking everything but QUICv1?

Thanks,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 13 Feb 2019 16:21:13 -0600

Hi, Roberto,

> Better that they have to explicitly block than they accidentally block?

Well, right, but I'm not sure why someone accidentally blocking (especially
QUICv1) is less likely to do that because we created a registry.

But I asked Christian a question just before the IAB telechat today, so I
should probably wait to give him a chance to explain what he was thinking.

Spencer

> *From: *QUIC <[email-masked]> on behalf of Spencer Dawkins at IETF
> <[email-masked]>
> *Date: *Wednesday, February 13, 2019 at 10:03 AM
> *To: *Christian Huitema <[email-masked]>
> *Cc: *Ted Hardie <[email-masked]>, Roberto Peon <[email-masked]>, David
> Benjamin <[email-masked]>, Martin Thomson <[email-masked]>, Ian
> Swett <ianswett=[email-masked]>, David Schinazi <
> [email-masked]>, Mikkel Fahnøe Jørgensen <[email-masked]>, "
> [email-masked]" <[email-masked]>, Martin Duke <[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2019 10:46:58 +1100

> that the shifts are meaningless doesn't seem to advance the general goal.

If I understand David's proposal, these versions would have meaningful changes, or at least changes that go beyond the version number.  In TLS he has suggested a similar technique, with changes that are not compatible, but relatively easy to implement.  For instance, changing the salt for the Initial keys would be trivial to implement and make the protocol indecipherable.  Switching to ChaCha20-Poly1305 instead of AES-128-GCM would be another.  He also suggested that we reorder key fields, switch endianness of various encodings, rot13 extension codepoints, ... plus whatever you can imagine.  As long as it is easier to respond correctly to new versions than it is to build specific handling for every new permutation, the protocol designers win.

Now, I'm not sure if that is as good as having a good reason to deploy a new version, but there you are.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 13 Feb 2019 15:56:57 -1000

On 2/13/2019 12:21 PM, Spencer Dawkins at IETF wrote:

> Hi, Roberto, 
>
> On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Well, right, but I'm not sure why someone accidentally blocking
> (especially QUICv1) is less likely to do that because we created a
> registry. 
>
> But I asked Christian a question just before the IAB telechat today,
> so I should probably wait to give him a chance to explain what he was
> thinking.

OK, back to basics. The middle-boxes will only not do something if it
hurts them. Blocking a little guy or blocking some experiment will not
hurt them, because there will be few complaints. Blocking Google or some
other big site, on the other hand, yes that could hurt -- calls to
support line, complaints from ISP who bought the box, etc. So the
version will only not ossify if the big players grease it in a
meaningful way, or change it frequently.

There are two plausible ways there. One would be a "version of the
month", with at least a change in the clear text encryption key. The
other would be "versions for extensions", tied to for example the
negotiation of new transport parameters. In both cases, having something
like an IANA registry for the version number would help.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Wed, 13 Feb 2019 15:56:57 -1000

-- Christian Huitema

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 13 Feb 2019 18:33:03 -0800

I'm with Martin Duke in that even if we trust the IETF process to produce a
v2 quicly (sorry), middleboxes could just as simply do "version == 1 or 2".

I agree with Christian that we don't need *everyone* to do this; a few
heavy hitters ought to be enough to dissuade middleboxes from ossifying a
few versions.

I'm intrigued by the "version of the month" idea, which is perhaps similar
to David Benjamin's idea of running a QUIC version per Chrome cycle.
Perhaps big sites (Google, Facebook, anyone else) could periodically
publish their new equivalent versions on a wiki, and clients could keep up
with them?  Is there a more concrete proposal here?

On Wed, Feb 13, 2019 at 6:18 PM Christian Huitema <[email-masked]>
wrote:

> hurts them. Blocking a little guy or blocking some experiment will not hurt
> them, because there will be few complaints. Blocking Google or some other
> big site, on the other hand, yes that could hurt -- calls to support line,
> complaints from ISP who bought the box, etc. So the version will only not
> ossify if the big players grease it in a meaningful way, or change it
> frequently.
>
> There are two plausible ways there. One would be a "version of the month",
> with at least a change in the clear text encryption key. The other would be
> "versions for extensions", tied to for example the negotiation of new
> transport parameters. In both cases, having something like an IANA registry
> for the version number would help.
>
> -- Christian Huitema
>

---

From: Martin Duke <[email-masked]>
Date: Wed, 13 Feb 2019 19:54:30 -0800

Just to close the loop on the transport parameter concern: changing the
salt probably solves the problem. You can't read the TPs unless the
implementer has processed the new version document.

I like how the version # discussion is progressing, please keep at it.

On Wed, Feb 13, 2019, 6:33 PM Jana Iyengar <[email-masked] wrote:

> I'm with Martin Duke in that even if we trust the IETF process to produce
> a v2 quicly (sorry), middleboxes could just as simply do "version == 1 or
> 2".
>
>> month", with at least a change in the clear text encryption key. The other
>> would be "versions for extensions", tied to for example the negotiation of
>> new transport parameters. In both cases, having something like an IANA
>> registry for the version number would help.
>>
>> -- Christian Huitema
>>
>

---

From: Martin Duke <[email-masked]>
Date: Wed, 13 Feb 2019 20:00:05 -0800

Would it make sense for "version of the month" to have essentially random
version numbers, rather than have them increase monotonically?

Similarly, setting aside IANA, is it sufficient for big players to accept
ANY version in the short term and treat it as v1, and also have their
clients propose totally random versions?

On Wed, Feb 13, 2019, 7:54 PM Martin Duke <[email-masked] wrote:

>> I'm intrigued by the "version of the month" idea, which is perhaps
>> similar to David Benjamin's idea of running a QUIC version per Chrome
>> cycle. Perhaps big sites (Google, Facebook, anyone else) could periodically
>>> But I asked Christian a question just before the IAB telechat today, so
>>> I should probably wait to give him a chance to explain what he was
>>> thinking.
>>>
>>>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2019 15:09:10 +1100

> clients propose totally random versions?

That would (or maybe only could) prevent us from using the version field for anything other than v1.

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 13 Feb 2019 20:48:02 -0800

> for anything other than v1.

Yes, agreed. There's no horizon for how long older versions circulate on
the Internet. We can't assign all versions to v1 for the "short term"
because we simply can't control when that term ends.
I don't think we need to specify how versions are assigned. We just need to
ensure that there are no collisions. We can use a wiki or IANA for this.

There's a problem this exposes though. v2 is defined as version == 2, and
we won't be able to use that for greasing v1. By extension, we won't be
able to use the IETF reserved versions. If we're going to do this right, I
would suggest that we separate on the wire version numbers from the QUIC
(abstract) versions entirely. I know this makes it a bit harder to reason
about from looking at packets on the wire, but that's exactly what we're
trying to accomplish -- it shouldn't be easy to reason about versions from
looking at packets on the wire.

Basically, I'm proposing that QUIC v1 be assigned a random number for its
version at RFC publication time. IANA can be used to reserve subsequent
on-the-wire version numbers for v1. Anyone who wants to use a different
version for v1 MUST request it from IANA first before using it in the wild.
QUIC v2 will similarly have a random value assigned to it at RFC
publication time.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2019 16:08:38 +1100

On Thu, Feb 14, 2019, at 15:48, Jana Iyengar wrote:
> version at RFC publication time. 

What property do you expect that to provide?

> Anyone who wants to use a different version for v1 MUST request it from IANA first before using it in the wild. 

This too.  What does this achieve?

I get that there seems to be the emerging view that unmanaged codepoint space is not good and we should ask IANA to manage it for us, but I don't understand what these proposals would provide.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 14 Feb 2019 05:59:06 +0000

Version of the month is problematic:

Google server would need to support a basic V1, otherwise non-chrome user agents would fail. Chrome browsers would have to reject V1 or the greasing won’t work. This can only happen towards Google servers. Middleboxes now check for V1 or Google domain. Eith future encrypted request domain, it is a perfect wsy to firewall Google via Chrome. Users switch to other browser.

________________________________
Fra: QUIC <[email-masked]> på vegne af Martin Thomson <[email-masked]>
Sendt: torsdag, februar 14, 2019 6:08 AM
Til: Jana Iyengar
Cc: QUIC WG
Emne: Re: QUIC ossification

---

From: Ted Hardie <[email-masked]>
Date: Thu, 14 Feb 2019 08:14:44 -0800

On Wed, Feb 13, 2019 at 3:47 PM Martin Thomson <[email-masked]> wrote:

> If I understand David's proposal, these versions would have meaningful
> changes, or at least changes that go beyond the version number.  In TLS he
> has suggested a similar technique, with changes that are not compatible,
> but relatively easy to implement.  For instance, changing the salt for the
> Initial keys would be trivial to implement and make the protocol
> indecipherable.

Changing the salt is the kind of thing I had in mind for "artificially
create that shift."  That's easy to do in a closed system; it's possible in
a standards-based one, but the overall impact on functionality is so low,
that the rate of uptake will be low.  So you will do version negotiation
down to the old version a lot of the time, I'm guessing.

>   Switching to ChaCha20-Poly1305 instead of AES-128-GCM would be another.
> He also suggested that we reorder key fields, switch endianness of various
> encodings, rot13 extension codepoints, ... plus whatever you can imagine.
> As long as it is easier to respond correctly to new versions than it is to
> build specific handling for every new permutation, the protocol designers
> win.
>
As a personal opinion, I think we have enough semantic additions to do here
that we don't need an artificial version which will have no natural driver
of adoption.

Ted

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 14 Feb 2019 12:12:55 -0600

Hi, Christian,

Thanks for the reply (which made perfect sense to me, and was helpful to
me), but I was also asking the question below (which may have not popped
out as the thread continued). So, backing up to this note:

> I'm sure I'm missing something here ...

I had guesses about why you suggested a registry, but I was guessing, and
thought it better to ask what you were thinking.

Thanks,

Spencer

---

From: Christian Huitema <[email-masked]>
Date: Thu, 14 Feb 2019 09:08:38 -1000

> On Feb 14, 2019, at 8:12 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Christian, 
> 
> Thanks for the reply (which made perfect sense to me, and was helpful to me), but I was also asking the question below (which may have not popped out as the thread continued). So, backing up to this note: 
> 
>> On Wed, Feb 13, 2019 at 12:02 PM Spencer Dawkins at IETF <[email-masked]> wrote:
>> Hi, Christian, 
>> 
>>> On Wed, Feb 13, 2019 at 11:28 AM Christian Huitema <[email-masked]> wrote:
> I had guesses about why you suggested a registry, but I was guessing, and thought it better to ask what you were thinking.

Communication between implementations. The point was already made in the thread. Rotation was easy in gQuic because there was only one implementation. If we want rotation between multiple teams, an IANA registry does that.

I think rotation will also require clients to maintain a cache of the last version supported by a server. The synchronization process could work like this:

1) client implements the new version, keeps proposing the old one.

2) server implements the new version, documents it in list of supported versions in transport parameters.

3) client connects to server with old version, notices that new version is supported, remembers that.

4) client uses new version for next connection.

-- Christian Huitema

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 14 Feb 2019 13:58:24 -0600

Hi, Christian,

On Thu, Feb 14, 2019 at 1:08 PM Christian Huitema <[email-masked]>
wrote:

> Communication between implementations. The point was already made in the
> thread. Rotation was easy in gQuic because there was only one
> implementation. If we want rotation between multiple teams, an IANA
> registry does that.
>

Ah. That helps.

I was thinking about it from the other perspective - there's an IANA
registry for QUIC versions because new ones appear so often, and if you
want to block stuff off your network when you have no idea what it is, feel
free to block stuff that's not in the registry, but the versions being
added in the registry are specified and people are trying to use them, so
sooner or later, you'll get tired of changing your firewalls to accept new
versions.

The point elsewhere in the thread about having a few large traffic sources
using multiple versions was also helpful.

Spencer

I think rotation will also require clients to maintain a cache of the last
> version supported by a server. The synchronization process could work like
> this:
>

---

From: David Benjamin <[email-masked]>
Date: Thu, 14 Feb 2019 14:38:37 -0600

At least in the TLS incarnation of this idea, yes, the point would be to
support both V1 (for normal clients) and the rolling version. That does not
require the client reject V1 for this to work, presuming your version
negotiation has downgrade protection. (Being forced onto a version other
than what you would have naturally negotiated is a downgrade.)

I'm not familiar with QUIC's negotiation mechanisms, but I certainly hope
you all are downgrade-protected. That's generally important independent of
these kinds of games.

David

On Wed, Feb 13, 2019 at 11:59 PM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> Google server would need to support a basic V1, otherwise non-chrome user
> agents would fail. Chrome browsers would have to reject V1 or the greasing
> won’t work. This can only happen towards Google servers. Middleboxes now
> check for V1 or Google domain. Eith future encrypted request domain, it is
> a perfect wsy to firewall Google via Chrome. Users switch to other browser.
>
>
> ------------------------------
> *Fra:* QUIC <[email-masked]> på vegne af Martin Thomson <
> [email-masked]>
> *Sendt:* torsdag, februar 14, 2019 6:08 AM
> *Til:* Jana Iyengar
> *Cc:* QUIC WG
> *Emne:* Re: QUIC ossification
>
> I get that there seems to be the emerging view that unmanaged codepoint
> space is not good and we should ask IANA to manage it for us, but I don't
> understand what these proposals would provide.
>
>

---

From: Mike Bishop <[email-masked]>
Date: Thu, 14 Feb 2019 20:41:52 +0000

We actually agreed at the interim to leave downgrade protection as future work, since this is currently the only version we care about.  A future version would need to be accompanied by an extension to v1 that provides downgrade protection.  🙂

If we start actively flexing version negotiation, of course, we probably need to revisit that decision.

From: QUIC <[email-masked]> On Behalf Of David Benjamin
Sent: Thursday, February 14, 2019 12:39 PM
To: Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Jana Iyengar <[email-masked]>; QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>
Subject: Re: QUIC ossification

At least in the TLS incarnation of this idea, yes, the point would be to support both V1 (for normal clients) and the rolling version.. That does not require the client reject V1 for this to work, presuming your version negotiation has downgrade protection. (Being forced onto a version other than what you would have naturally negotiated is a downgrade.)

I'm not familiar with QUIC's negotiation mechanisms, but I certainly hope you all are downgrade-protected. That's generally important independent of these kinds of games.

David
On Wed, Feb 13, 2019 at 11:59 PM Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>> wrote:
Version of the month is problematic:

________________________________
Fra: QUIC <[email-masked]<mailto:[email-masked]>> på vegne af Martin Thomson <[email-masked]<mailto:[email-masked]>>
Sendt: torsdag, februar 14, 2019 6:08 AM
Til: Jana Iyengar
Cc: QUIC WG
Emne: Re: QUIC ossification

---

From: David Schinazi <[email-masked]>
Date: Thu, 14 Feb 2019 12:54:29 -0800

Yes, the version downgrade prevention was punted to whenever we start using
another production version and performing in-band version negotiation.
These rolling versions would qualify as such and absolutely require
downgrade prevention if we have version negotiation inside QUIC.

That said, an important difference between TLS and QUIC here is Alt-Svc. We
don't need 100% of QUIC uses to use this rolling version to prevent
ossification, it would be fine if only HTTP/3 clients did that.
Those clients will know the server-supported versions thanks to Alt-Svc, so
there is no need for in-band version negotiation between these versions.

It would be feasible to deploy these rolling versions while still treating
any Version Negotiation packet as a critical error.

David

On Thu, Feb 14, 2019 at 12:42 PM Mike Bishop <[email-masked]> wrote:

> We actually agreed at the interim to leave downgrade protection as future
> work, since this is currently the only version we care about.  A future
> version would need to be accompanied by an extension to v1 that provides
> downgrade protection.  🙂
>
>
>
> *From:* QUIC <[email-masked]> *On Behalf Of * David Benjamin
> *Sent:* Thursday, February 14, 2019 12:39 PM
> *To:* Mikkel Fahnøe Jørgensen <[email-masked]>
> *Cc:* Jana Iyengar <[email-masked]>; QUIC WG <[email-masked]>; Martin
> Thomson <[email-masked]>
> support both V1 (for normal clients) and the rolling version.. That does
> not require the client reject V1 for this to work, presuming your version
> On Wed, Feb 13, 2019 at 11:59 PM Mikkel Fahnøe Jørgensen <
> [email-masked]> wrote:
>

---

From: Martin Duke <[email-masked]>
Date: Thu, 14 Feb 2019 17:02:32 -0800

Collective, time for me to file a github issue? Or leave it on the list?

On Thu, Feb 14, 2019, 12:54 PM David Schinazi <[email-masked]
wrote:

> Yes, the version downgrade prevention was punted to whenever we start
> using another production version and performing in-band version
> negotiation. These rolling versions would qualify as such and absolutely
> require downgrade prevention if we have version negotiation inside QUIC.
>
> That said, an important difference between TLS and QUIC here is Alt-Svc.
> We don't need 100% of QUIC uses to use this rolling version to prevent
> Those clients will know the server-supported versions thanks to Alt-Svc,
> so there is no need for in-band version negotiation between these versions.
>
>> mt@lowentropy..net <[email-masked]>>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 14 Feb 2019 20:04:33 -0500

> Collective, time for me to file a github issue? Or leave it on the list?

What do you believe the issue would be?  Because a lot of the discussion here has been very much "quicv2" territory.

---

From: David Schinazi <[email-masked]>
Date: Thu, 14 Feb 2019 17:09:28 -0800

One potential change to v1 that has come out of this discussion is that we
could change the 32bit version number from 0x00000001 to a value randomly
generated at RFC publication time.

On Thu, Feb 14, 2019 at 17:04 Martin Thomson <[email-masked]> wrote:

> What do you believe the issue would be?  Because a lot of the discussion
> here has been very much "quicv2" territory.
>
>

---

From: Martin Duke <[email-masked]>
Date: Thu, 14 Feb 2019 17:11:07 -0800

I think we are edging towards shenanigans in v1 deployments, possibly
involving IANA action?

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 14 Feb 2019 20:13:15 -0500

On Fri, Feb 15, 2019, at 12:09, David Schinazi wrote:
> One potential change to v1 that has come out of this discussion is that 
> we could change the 32bit version number from 0x00000001 to a value 
> randomly generated at RFC publication time.

I didn't get an answer to my questions about that, because that seems silly.

> I think we are edging towards shenanigans in v1 deployments, possibly 

The IANA bit would be a good one to track.  For some reason that is lost to me, we decided not to have IANA manage this space.  I never really understood how that was supposed to work, so I would definitely support having them take that bit over.

---

From: Ian Swett <[email-masked]>
Date: Thu, 14 Feb 2019 20:22:06 -0500

> I didn't get an answer to my questions about that, because that seems

I believe the concern is that a middlebox/etc will conclude that a certain
range of versions are IETF standard versions and should be allowed and
others are fine to block because they're experimental, thereby making the
majority of versions largely undeployable.

> The IANA bit would be a good one to track.  For some reason that is lost
> to me, we decided not to have IANA manage this space.  I never really
> understood how that was supposed to work, so I would definitely support
> having them take that bit over.
>
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 14 Feb 2019 21:43:06 -0500

On Fri, Feb 15, 2019, at 12:22, Ian Swett wrote:
> I believe the concern is that a middlebox/etc will conclude that a 
> certain range of versions are IETF standard versions and should be 
> allowed and others are fine to block because they're experimental, 
> thereby making the majority of versions largely undeployable.

That only suggests to me that we not segregate the space.  The proposed variations won't all happen in that space.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 15 Feb 2019 07:33:09 +0000

It would be useful with a private version range that can be deployed in a limited context without involving IANA.

________________________________
Fra: QUIC <[email-masked]> på vegne af Martin Thomson <[email-masked]>
Sendt: fredag, februar 15, 2019 3:43 AM
Til: [email-masked]
Emne: Re: QUIC ossification

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 15 Feb 2019 07:53:42 -0600

Speaking as an individual who is trying to be helpful :-)

On Fri, Feb 15, 2019 at 1:33 AM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> *Sendt:* fredag, februar 15, 2019 3:43 AM
> *Til:* [email-masked]
> That only suggests to me that we not segregate the space. The proposed
> variations won't all happen in that space.
>

 So, yes, I get the interest in being able to dork around without
immediately having to involve IANA, and I think you're both exactly right
to point to the tension/tussle between people wanting to know what they're
admitting and people wanting to experiment.

ISTM (keeping in mind that TSV ADs are stuckees for appointing services and
port number registry expert reviewers) that this is EXACTLY analogous to
transport-level port numbers, except (for extra credit) all the transport
stuff in QUIC is encrypted, so anyone who cares about what they're
admitting has to look at something else, and if anyone has a better
suggestion than looking at version numbers, you should probably tell the
working group, which will immediately encrypt it :D

So - if you don't want people to squat on version numbers, which has been
problematic for port numbers since the 1980s, you probably want a
segregated version number space for experiments, and if you think (or
observe) that people who care what traffic they are admitting are blocking
experimental version numbers, you probably want that space to be so small
that it really can't be used for wide-scale, long-term deployments.

I'll stop typing now, and let people like Lars, who has forgotten more
about port number reviews than I've ever known, tell me why this is a bad
plan ;-) ...

Spencer, again, as individual

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Sat, 16 Feb 2019 23:18:19 +0100

hi Ian, all,

> On 15 Feb 2019, at 02:22, Ian Swett <ianswett=[email-masked]> wrote:
> 
> I believe the concern is that a middlebox/etc will conclude that a certain range of versions are IETF standard versions and should be allowed and others are fine to block because they're experimental, thereby making the majority of versions largely undeployable.

So if I understand the proposal behind this correctly, then, there would be no segregation of the version number space (aside from "grease" and "nongrease"), the entire non-assigned version number space would be IANA-managed FCFS, and the IETF-standard versions would grab random codepoints out of that FCFS space at publication time?

That fixes the "middleboxes preferentially block experimental versions" problem, at the expense of maybe edging them toward blocking everything that isn't IETF-V1. 

This is of course assuming that middleboxes exist that have an incentive to block non-V1 versions while letting V1 versions through. I could maybe see firewalls with default-deny policies wanting to "offer" this, but I don't see why a box deployed to blocking any QUIC on purpose would need to be picky about version numbers. Given that the TCP fallback makes it connectivity-safe to block *all* QUIC while also gaining the "advantages" (from the middlebox PoV, with respect to wire-image accessibility and wire-image editability) of TCP, just turning QUIC off is easier than having to keep per-flow VN outcome state.

going back to a point Ted made on Thursday, though:

> As a personal opinion, I think we have enough semantic additions to do here that we don't need an artificial version which will have no natural driver of adoption.

+1 to this.

I think I've said this before, maybe multiple times: the only way to keep version negotiation from ossifying it is to use it for real. I'd argued for shipping v1 and v2 simultaneously, perhaps with different feature profiles (indeed, we even discussed using the spin bit as a version-differentiator to exercise VN, but this turned out to not work very well for spin-bit-and-connection-ID physics reasons). It seems we're not going to do that: we'll ship v1 and start work on v2 after that.

I observe that there's an ossification window for version negotiation that arises as a logical consequence of the process we're following: after v2 ships, if it sees wide deployment, version negotiation as a mechanism will be protected (yeah sure some lazy middleboxes might hardcode two version numbers, but see above for my skepticism about the likelihood of that). Until then, it will not (grease notwithstanding, but grease isn't real protection for VN because it's safe to ignore). 

The risk of VN breaking is a function of how long that window is, and how quickly middleboxes that understand QUIC versioning will deploy. Recent proposals (I forget the details, have been paying only cursory attention during my month off) to punt VN to version 2 in essence make a pessimistic bet about this risk: anything we can design will be broken by the time we try to use it, so let's design it later. 

I think if we care about designing VN into V1 that has a chance of working, though, being aggressive about shipping V2 is the only action under our control as a WG.

Cheers,

Brian

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 18 Feb 2019 19:35:53 -0800

> variations won't all happen in that space.

The whole point of the proposal was to avoid segregating this space. Let me
articulate a bit better, and folks can poke holes.

Whatever we choose for the on-wire representation of version 1, that's
visible to mboxes and they can ossify around it. We want more versions on
the wire to avoid this from happening.  As long as a few major players use
a few more versions on the wire besides v1, that's all we need to keep the
ecosystem from ossifying.

Ideally, the additional versions keep changing over time to avoid those
getting ossified as well. So a server can simply choose a random version
periodically and use it. But we need clients to use the version as well,
and since not everyone is Google, we use IANA to publish this new version.
Basically, (i) org requests new version from IANA, (ii) IANA either assigns
a new version (randomly) or approves the requested version for use as
additional v1, and (iii) clients and servers roll out support for this new
version. Note again that all servers and clients continue supporting the
original v1 version; this is an additional preferred version when it is
available on both sides. This gets us greasing, and ensures that we have a
mechanism in play that protects against downgrade protection.

Let's say we use 0x00000001 as v1. Do we allow 0x00000002 as an additional
version for v1? If we do, then what is the on-wire representation for v2?
If we don't, then we have to segregate the space. To avoid this problem, I
suggested that we randomize everything. It's not that hard: IANA can easily
assign a version to us at RFC publication time much in the same way as they
would to anyone requesting an additional on-wire version for v1 in the
future.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 18 Feb 2019 23:22:44 -0800

I still think there is a need for private experimentation without going all
IANA.

If randomisation is a good idea, why not have 128-bit version identifiers -
each org with special needs can encrypt their own version numbers.
Now you have fully randomised keys and infinitely many spaces.
Since the VN’s are only used in a few header packets, 128-bits is a fine
length.

Mikkel

On 19 February 2019 at 04.36.21, Jana Iyengar ([email-masked]) wrote:

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 19 Feb 2019 10:51:48 -0500

On Mon, Feb 18, 2019, at 19:36, Jana Iyengar wrote:
> Let's say we use 0x00000001 as v1. Do we allow 0x00000002 as an 
> additional version for v1? If we do, then what is the on-wire 
> representation for v2? If we don't, then we have to segregate the 
> space. To avoid this problem, I suggested that we randomize everything. 
> It's not that hard: IANA can easily assign a version to us at RFC 
> publication time much in the same way as they would to anyone 
> requesting an additional on-wire version for v1 in the future.

I don't think that there is much value in using two version numbers to refer to the same protocol.  But even if we did, as long as we didn't establish any pattern in doing so, that couldn't be used against us.  So I might tentatively agree that 0x1 == 0x2 would be inadvisable, there is no strong need to do anything special with the first version.  Any attempt to profile QUIC will be done with full knowledge of the version number we pick, so randomness doesn't serve any real purpose.  Subsequent versions might need to use a randomized value, but we can make that decision then.

The problem of course being that as long as v1 remains, we might find places that no other version does.  The QUIC "magic number" will be whatever we pick, and we can't prevent someone from fixating on that.  We'll convince those people in the same way they will be convinced to open up UDP for QUIC version 1: by making a QUIC version 2 worth enabling.

I completely get the don't segregate thing.  But to - I think - Mikkel's point about experimentation without permission, I do think that squatting is a perfectly sound approach in a space this big.  TLS people do it in a much smaller space.  As long squatters pick random values, they do so infrequently, and they get IANA registrations for codepoints relatively soon afterwards, the risk of collision is low.  Randomness here is useful - but primarily as a collision-avoidance technique.  The TLS extension codepoint 26 is a great example of why.  Keeping the bar on registrations low (FCFS is a reasonable policy) would also have the effect of making the pool of apparent versions larger, which might be more effective than any other strategy we might employ.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 19 Feb 2019 10:51:51 -0800

On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson <[email-masked]> wrote:

>
> I completely get the don't segregate thing.  But to - I think - Mikkel's
> point about experimentation without permission, I do think that squatting
> is a perfectly sound approach in a space this big.  TLS people do it in a
> much smaller space.  As long squatters pick random values, they do so
> infrequently, and they get IANA registrations for codepoints relatively
> soon afterwards, the risk of collision is low.

The difficulty, of course, is that squatters use whatever process they like
for picking code points and it is easier to be lazy*.  One way out of this
is to have IANA generate random values for "unregistered" codepoints and
block those from appearing in the public registry for a period of time
(say, 6 months). At the end of six months they must either be formally
registered or dropped.  A slightly different, but probably similar effect
can be gotten by IANA generating random codepoints for a shifting
experimental range; they put out N code points at time T and age them out
and replace them at some interval afterwards.  That would, as a side
effect, give you a changing random pool that middleboxes would likely want
to track, rather than a static small number of versions.

Ted

*I have anecdata on this from ULAs but it is depressing enough that you
probably don't want to see it.

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 19 Feb 2019 15:09:55 -0800

On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson <[email-masked]> wrote:

> I don't think that there is much value in using two version numbers to
> refer to the same protocol.  But even if we did, as long as we didn't
> establish any pattern in doing so, that couldn't be used against us.  So I
> might tentatively agree that 0x1 == 0x2 would be inadvisable, there is no
> strong need to do anything special with the first version.  Any attempt to
> profile QUIC will be done with full knowledge of the version number we
> pick, so randomness doesn't serve any real purpose.  Subsequent versions
> might need to use a randomized value, but we can make that decision then.
>

I figured that making all version assignments random instead of
special-casing 0x1 made it simpler to reason about and uniform to code for,
but I actually don't care about the IANA assignment for v1 for the reason
you note. v1 will be one specific bit-pattern on the wire to start of with,
and that can just as well be 0x1. It still does segregate the space, but we
can't do anything about it anyways - it'll be 0x1 or some other random
number getting special treatment.

The problem of course being that as long as v1 remains, we might find
> places that no other version does.  The QUIC "magic number" will be
> whatever we pick, and we can't prevent someone from fixating on that.
> We'll convince those people in the same way they will be convinced to open
> up UDP for QUIC version 1: by making a QUIC version 2 worth enabling.
>

That was the entire point of having alternate and preferred versions to
0x1. If we have downgrade protection in place, and if there are those who
try alternate version numbers for v1, that gives us what we need at the
endpoints. I believe that there would be interest at some major vendors to
do this at some endpoints. Presumably, we can convince Google to do
something, since it has been bit by mbox ossification in the past. I am
operating on the premise that we have buy in from a few major providers.

IANA is for me a publication venue where these alternate versions are
published and other clients/servers interested in keeping the ecosystem
from ossifying can use these alternate versions as well.

> soon afterwards, the risk of collision is low.  Randomness here is useful -
> but primarily as a collision-avoidance technique.  The TLS extension
> codepoint 26 is a great example of why.  Keeping the bar on registrations
> low (FCFS is a reasonable policy) would also have the effect of making the
> pool of apparent versions larger, which might be more effective than any
> other strategy we might employ.
>

I'm totally fine with experimentation without permission, and using random
to avoid collision. My point was entirely about using alternate on-wire
version numbers for v1. Nothing here about new or experimental versions.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 19 Feb 2019 23:14:26 +0000

As others have intimated in some form or another, you can also use multiple numbers to express “version 1”.

For instance, pick 64 (or some similar constant) random numbers, and call them all version 1.
-=R

From: QUIC <[email-masked]> on behalf of Jana Iyengar <[email-masked]>
Date: Tuesday, February 19, 2019 at 3:10 PM
To: Martin Thomson <[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: Re: QUIC ossification

On Tue, Feb 19, 2019 at 7:52 AM Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
I don't think that there is much value in using two version numbers to refer to the same protocol.  But even if we did, as long as we didn't establish any pattern in doing so, that couldn't be used against us.  So I might tentatively agree that 0x1 == 0x2 would be inadvisable, there is no strong need to do anything special with the first version.  Any attempt to profile QUIC will be done with full knowledge of the version number we pick, so randomness doesn't serve any real purpose.  Subsequent versions might need to use a randomized value, but we can make that decision then.

I figured that making all version assignments random instead of special-casing 0x1 made it simpler to reason about and uniform to code for, but I actually don't care about the IANA assignment for v1 for the reason you note. v1 will be one specific bit-pattern on the wire to start of with, and that can just as well be 0x1. It still does segregate the space, but we can't do anything about it anyways - it'll be 0x1 or some other random number getting special treatment.

The problem of course being that as long as v1 remains, we might find places that no other version does.  The QUIC "magic number" will be whatever we pick, and we can't prevent someone from fixating on that..  We'll convince those people in the same way they will be convinced to open up UDP for QUIC version 1: by making a QUIC version 2 worth enabling.

That was the entire point of having alternate and preferred versions to 0x1. If we have downgrade protection in place, and if there are those who try alternate version numbers for v1, that gives us what we need at the endpoints. I believe that there would be interest at some major vendors to do this at some endpoints. Presumably, we can convince Google to do something, since it has been bit by mbox ossification in the past. I am operating on the premise that we have buy in from a few major providers.

IANA is for me a publication venue where these alternate versions are published and other clients/servers interested in keeping the ecosystem from ossifying can use these alternate versions as well.

I'm totally fine with experimentation without permission, and using random to avoid collision. My point was entirely about using alternate on-wire version numbers for v1. Nothing here about new or experimental versions.

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 19 Feb 2019 15:17:19 -0800

Roberto -- yes, that's basically what I'm proposing too, just one variant
of how to go about doing it dynamically over time.

On Tue, Feb 19, 2019 at 3:14 PM Roberto Peon <[email-masked]> wrote:

> *From: *QUIC <[email-masked]> on behalf of Jana Iyengar <
> [email-masked]>
> *Date: *Tuesday, February 19, 2019 at 3:10 PM
> *To: *Martin Thomson <[email-masked]>
> *Cc: *QUIC WG <[email-masked]>
> whatever we pick, and we can't prevent someone from fixating on that..

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 20 Feb 2019 07:58:53 +0100

hi Jana,

The middlebox adaptation model that this proposal addresses seems limited to middleboxes built based on naive traffic analysis and pre-QUIC assumptions about wire images. This is admittedly the model behind one of Google's experiences with QUIC middlebox breakage, and the one we seem most concerned with because by definition we cannot fix it by writing things in documents.

> On 20 Feb 2019, at 00:17, Jana Iyengar <[email-masked]> wrote:
> 
> Roberto -- yes, that's basically what I'm proposing too, just one variant of how to go about doing it dynamically over time.
>

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 20 Feb 2019 08:03:46 +0100

(oops, hit send too soon...)

> On 20 Feb 2019, at 07:58, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> hi Jana,
> 

I don't think these are the only things we're concerned about though. Concerns about partitioning VN space have a less naive model in mind: here we think more about default-deny firewalls that have been told that some versions of QUIC are okay but all others are not. As noted before I personally cannot think of a reason an operator would want to do this -- if you've already decided to allow a protocol with low observability and built-in extensibility as a design goal on your network, does the exact flavor really matter all that much? -- but it's a checkbox on the firewall feature list so yeah, I suppose someone will ship it.

Are there other middlebox adaptation models we are concerned about here?

Cheers,

Brian

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 21 Feb 2019 20:23:57 -0800

Brian,

I agree that there are potentially other models as well, but the one we
know from experience is the naive one.  We should at least protect against
the one model we know, naive or not. I'll note that it quickly gets
difficult to come up with measures if we assume a smarter ossifier.

- jana

On Tue, Feb 19, 2019 at 11:03 PM Brian Trammell (IETF) <[email-masked]>
wrote:

> > The middlebox adaptation model that this proposal addresses seems
> limited to middleboxes built based on naive traffic analysis and pre-QUIC
> assumptions about wire images. This is admittedly the model behind one of
> Google's experiences with QUIC middlebox breakage, and the one we seem most
> concerned with because by definition we cannot fix it by writing things in
> documents.
>
> I don't think these are the only things we're concerned about though.
> Concerns about partitioning VN space have a less naive model in mind: here
> we think more about default-deny firewalls that have been told that some
> versions of QUIC are okay but all others are not. As noted before I
> personally cannot think of a reason an operator would want to do this -- if
> you've already decided to allow a protocol with low observability and
> built-in extensibility as a design goal on your network, does the exact
> flavor really matter all that much? -- but it's a checkbox on the firewall
> feature list so yeah, I suppose someone will ship it.
>
> >> Roberto -- yes, that's basically what I'm proposing too, just one
> variant of how to go about doing it dynamically over time.
> >>
> >> I completely get the don't segregate thing.  But to - I think -
> Mikkel's point about experimentation without permission, I do think that
> squatting is a perfectly sound approach in a space this big.  TLS people do
> it in a much smaller space.  As long squatters pick random values, they do
> so infrequently, and they get IANA registrations for codepoints relatively
> >> I'm totally fine with experimentation without permission, and using
> random to avoid collision. My point was entirely about using alternate
> on-wire version numbers for v1. Nothing here about new or experimental
> versions.
> >>
> >>
> >>
> >
>
>

---

From: Erik Kline <[email-masked]>
Date: Thu, 21 Feb 2019 22:02:00 -0800

> difficult to come up with measures if we assume a smarter ossifier.

You would pretty much have to move version negotiation bits (and subsequent
protocol differences) to underneath the crypto umbrella, wouldn't you?
Negotiating a newer version would have to be like negotiating some
extensions, or something, I would think...

- jana
>> >> That was the entire point of having alternate and preferred versions
>> to 0x1. If we have downgrade protection in place, and if there are those
>> who try alternate version numbers for v1, that gives us what we need at the

---

From: Roberto Peon <[email-masked]>
Date: Fri, 22 Feb 2019 21:35:25 +0000

This would be “fun” (i.e. somewhat hard) to attempt to match via simple filtering rules :
   When expressed in-the-clear, version is expressed as two var-ints, which are summed and modulo 2^16
i.e.
   version = (decodeVarInt() + decodeVarInt()) % (1 << 16)
-=R

From: Erik Kline <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Thursday, February 21, 2019 at 10:02 PM
To: Jana Iyengar <[email-masked]>
Cc: "Brian Trammell (IETF)" <[email-masked]>, QUIC WG <[email-masked]>, Roberto Peon <[email-masked]>, Martin Thomson <[email-masked]>
Subject: Re: QUIC ossification

On Thu, 21 Feb 2019 at 20:24, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:
Brian,

I agree that there are potentially other models as well, but the one we know from experience is the naive one.  We should at least protect against the one model we know, naive or not. I'll note that it quickly gets difficult to come up with measures if we assume a smarter ossifier.

You would pretty much have to move version negotiation bits (and subsequent protocol differences) to underneath the crypto umbrella, wouldn't you?  Negotiating a newer version would have to be like negotiating some extensions, or something, I would think...

- jana

On Tue, Feb 19, 2019 at 11:03 PM Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
(oops, hit send too soon...)

> On 20 Feb 2019, at 07:58, Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
>
> hi Jana,
>

Cheers,

Brian

>> On 20 Feb 2019, at 00:17, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> On Tue, Feb 19, 2019 at 3:14 PM Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:
>> From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Jana Iyengar <[email-masked]<mailto:[email-masked]>>
>> To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
>> Cc: QUIC WG <[email-masked]<mailto:[email-masked]>>

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 22 Feb 2019 18:06:46 -0500

Leaving the specifics of the proposal aside for the moment, the problem here is that we have no shared context AND we want to ensure that legitimate endpoints don't have to go to extreme measures to get the information they need.  A little obfuscation might get us somewhere (esp. if we are willing to burn either more octets or part of our existing space), but let's try to focus on what we think we're going to achieve by doing something here.

Funny that TLS are concurrently talking about hiding the existence of ESNI, which has so many of the same constraints: you have to standardize the semantics so that it can be decoded, but you would rather that only the intended recipient was able to read it.  In both cases, the answer is that you lose because you have no shared keys that would enable the only thing that we know works (crypto).  (I haven't ingested Stephen's long email there, maybe he has a brilliant idea for breaking the deadlock, but I doubt that it will help us here, because at least with ESNI you *maybe* have a key and it seems to be using crypto.)

On Fri, Feb 22, 2019, at 13:35, Roberto Peon wrote:
> *From: *Erik Kline <[email-masked]>
>  *Reply-To: *"[email-masked]" <[email-masked]>
>  *Date: *Thursday, February 21, 2019 at 10:02 PM
>  *To: *Jana Iyengar <[email-masked]>
>  *Cc: *"Brian Trammell (IETF)" <[email-masked]>, QUIC WG 
> <[email-masked]>, Roberto Peon <[email-masked]>, Martin Thomson 
> <[email-masked]>
> You would pretty much have to move version negotiation bits (and 
> subsequent protocol differences) to underneath the crypto umbrella, 
> wouldn't you? Negotiating a newer version would have to be like 
> negotiating some extensions, or something, I would think...
> 
>  
>  
>  
>  
> 
>  
>   
> >  
> >  
> > - jana
> 
> >  
> >  
> >  
> >  
> 
> >  
> >  
> >  
> > On Tue, Feb 19, 2019 at 11:03 PM Brian Trammell (IETF) <[email-masked]> wrote:
> 
> >  
> >

---

From: Christian Huitema <[email-masked]>
Date: Fri, 22 Feb 2019 19:03:11 -0800

> Funny that TLS are concurrently talking about hiding the existence of ESNI, which has so many of the same constraints: you have to standardize the semantics so that it can be decoded, but you would…

Martin, you seem uncharacteristically restrained today. How about, "If
it is not encrypted, middle boxes will ossify, and pathetic efforts at
obfuscation are not going to save you?"

I get the point about grease, etc. But grease mostly works between
semi-consenting endpoints, such as QUIC peers who might have forgotten
to actually implement a part of the extension mechanisms. Greasing
Transport Parameter codes, for example. In the case of version numbers,
we have a quandary. We can only use a scheme that is standard enough
that many implementations understand what a particular version means.
But if it is standard enough, then the villains that design the
middle-boxes will know everything about it, and won't stop stroking
their furry white cats for even a second.

-- Christian Huitema

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 22 Feb 2019 23:02:58 -0800

But if it is standard enough, then the villains that design the
middle-boxes will know everything about it, and won't stop stroking
their furry white cats for even a second

hear

I fear we are making the already complicated concept of vneg more difficult
without any actual benefit.

But if we must obfuscate, I’d prefer a longer version id of 128 bits and
use secure hash or crypto.

And if not, can’t we please make use of Fibonacci numbers somehow - Roberto
already suggested adding two numbers.

On 23 February 2019 at 04.03.35, Christian Huitema ([email-masked])
wrote:

On 2/22/2019 3:06 PM, Martin Thomson wrote:

> Leaving the specifics of the proposal aside for the moment, the problem
here is that we have no shared context AND we want to ensure that
legitimate endpoints don't have to go to extreme measures to get the
information they need. A little obfuscation might get us somewhere (esp. if
we are willing to burn either more octets or part of our existing space),
but let's try to focus on what we think we're going to achieve by doing
something here.
>
> Funny that TLS are concurrently talking about hiding the existence of
ESNI, which has so many of the same constraints: you have to standardize
the semantics so that it can be decoded, but you would rather that only the
intended recipient was able to read it. In both cases, the answer is that
you lose because you have no shared keys that would enable the only thing
that we know works (crypto). (I haven't ingested Stephen's long email
there, maybe he has a brilliant idea for breaking the deadlock, but I doubt
that it will help us here, because at least with ESNI you *maybe* have a
key and it seems to be using crypto.)

-- Christian Huitema

---

From: "Martin Thomson" <[email-masked]>
Date: Sat, 23 Feb 2019 13:20:56 -0500

> obfuscation are not going to save you?"

That is what I typed first... Maybe if we all agree on this point,  we can move on.

---

From: Jana Iyengar <[email-masked]>
Date: Sat, 23 Feb 2019 15:37:21 -0800

> That is what I typed first... Maybe if we all agree on this point,  we can

I've seen and worked through one ossification case with QUIC so far, I can
say that making versions dynamic in any way would have helped us. This is
after talking to the middlebox vendor, and understanding their process.

I think I've made my case -- that there's value in making the on-the-wire
version more dynamic. If there is a proposal to encrypt version number, I'm
all ears. This conversation is premised on not having encryption to save
us. Without a proposal that encrypts version numbers, it does not make
sense to say that encryption is the only solution.

It is counter-productive to argue that nothing should be done in any
situation when encryption is not available as a solution.

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 24 Feb 2019 10:26:59 +0900

2019年2月24日(日) 8:37 Jana Iyengar <[email-masked]>:
> I've seen and worked through one ossification case with QUIC so far, I can say that making versions dynamic in any way would have helped us. This is after talking to the middlebox vendor, and understanding their process.
>
> I think I've made my case -- that there's value in making the on-the-wire version more dynamic. If there is a proposal to encrypt version number, I'm all ears. This conversation is premised on not having encryption to save us. Without a proposal that encrypts version numbers, it does not make sense to say that encryption is the only solution.
>
> It is counter-productive to argue that nothing should be done in any situation when encryption is not available as a solution.

Yeah. And IIUC encryption cannot be a solution for QUIC v1.

To be precise, encryption can be a solution for QUIC v1 only when we
can assume that ESNI (or something other that allows the endpoints to
negotiate shared knowledge) gets deployed along with QUIC v1 by a
significant portion of the endpoints.

I'd be very happy to see that happen, but I am skeptical if it would.

-- 
Kazuho Oku

---

From: Roberto Peon <[email-masked]>
Date: Mon, 25 Feb 2019 18:27:01 +0000

You'd certainly get agreement that the only way to prevent things from reacting/recognizing to something is to make it unrecognizable as that something.

So, in the long-term we want some combination of encryption (bytes unrecognizable) and pattern/timing obfuscation. I'm sure we'd all be happy if we could have this tomorrow and thus apply to V1, but it seems unlikely.

If that is true, then for V1 the question is what potentially imperfect thing could we do that gives us the breathing room to get to V2, which could/should have the more perfect and more robust (likely encryption-based) solution?

The answer to that depends on our shared understanding of the threat model.

My understanding is that we're worried about accidental pattern-matching based "threats"-- i.e. protecting against assumptions that a particular range of bits in a particular place indicate the presence of QUIC.

-=R

On 2/23/19, 5:27 PM, "QUIC on behalf of Kazuho Oku" <[email-masked] on behalf of [email-masked]> wrote:

    

    -- 
    Kazuho Oku