Subject: Version Negotiation Greasing

From: "Martin Thomson" <[email-masked]>
Date: Sun, 07 Apr 2019 22:07:21 -0400

Philip's idea for greasing the version number field of the long packet header is an interesting one.  It creates a way for servers and clients to cooperatively negotiate new versions without state.  It encourages middleboxes to either:

a) allow new versions, because they routinely see new versions in use, or
b) block new versions and either block those connections or slow them down if clients retry

The question of whether retrying is necessary is an interesting one that we might want to take up before we conclude this.  I tend to think that as long as this mechanism comes with a commitment to support the version as long as QUIC is supported, retries won't be necessary.

The PR (https://github.com/quicwg/base-drafts/pull/2573, thanks Marten) includes not just a version number, but also a salt value, which I think is very important.  Clients can use the new fake version, with different encryption keys on every version.

Servers can avoid holding state by using a static key (maybe one derived from the same base as they use for stateless reset) and generating the salt from the version using a PRF, such as salt = HKDF-Expand-Label(static, "label for " + version.hex(), 16).  This allows servers to use all 2^32-2 spare version numbers without holding any significant amount of state.   As we add more versions, the version number space might need to be divided between different base versions, but this is still a good amount of variation.  The version number space might need to be divided further to allow rotation of the key over time, but that doesn't change the calculus much.

This seems like it could be subject to gaming by middleboxes, who can connect to the server and learn the salt for different versions.  However, if servers only offer a small number of fake versions in response to connection attempts  (1 is enough for this purpose, but more on that below), and those fake versions are selected randomly or using a counter, the work required to find a matching value goes up pretty significantly.  2^16 connections are required to have a 50% chance of getting the same value if they are chosen randomly; and - counter-intuitively - more if the server supports >1 version because the middlebox needs to make connections in all possible versions.

The state a middlebox needs to commit to remembering all salt values is pretty high - assuming that the entire space is covered. This is in the order of 2^36 bytes if we insist on a 16 byte salt, though we might reasonably insist on longer salts.  Our current salt is 20 bytes, and 32 byte salt is no more expensive to compute or produce with HKDF-SHA256, so we could probably go that high.

So I think that this is a good change, the best we can do in our current state.  I do think that it needs a little more text about the operation of this mechanism, and we still need to sort out the lifetime thing, but it's pretty good.  I might propose some text amendments.

This might be better attached to NEW_TOKEN, which corresponds more closely with connection establishment patterns.  A transport parameter is simpler, but the use of a version number will link sessions, so you can't realistically use a fake version over multiple connections.  That suggests to me that altering NEW_TOKEN is better than what is proposed.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 8 Apr 2019 00:27:59 -0700

Should we consider a longer version number to reduce the chance of odd
conflicts?

Mikkel

On 8 April 2019 at 04.07.35, Martin Thomson ([email-masked]) wrote:

Philip's idea for greasing the version number field of the long packet
header is an interesting one. It creates a way for servers and clients to
cooperatively negotiate new versions without state. It encourages
middleboxes to either:

a) allow new versions, because they routinely see new versions in use, or
b) block new versions and either block those connections or slow them down
if clients retry

The question of whether retrying is necessary is an interesting one that we
might want to take up before we conclude this. I tend to think that as long
as this mechanism comes with a commitment to support the version as long as
QUIC is supported, retries won't be necessary.

The PR (https://github.com/quicwg/base-drafts/pull/2573, thanks Marten)
includes not just a version number, but also a salt value, which I think is
very important. Clients can use the new fake version, with different
encryption keys on every version.

Servers can avoid holding state by using a static key (maybe one derived
from the same base as they use for stateless reset) and generating the salt
from the version using a PRF, such as salt = HKDF-Expand-Label(static,
"label for " + version.hex(), 16). This allows servers to use all 2^32-2
spare version numbers without holding any significant amount of state. As
we add more versions, the version number space might need to be divided
between different base versions, but this is still a good amount of
variation. The version number space might need to be divided further to
allow rotation of the key over time, but that doesn't change the calculus
much.

This seems like it could be subject to gaming by middleboxes, who can
connect to the server and learn the salt for different versions. However,
if servers only offer a small number of fake versions in response to
connection attempts (1 is enough for this purpose, but more on that below),
and those fake versions are selected randomly or using a counter, the work
required to find a matching value goes up pretty significantly. 2^16
connections are required to have a 50% chance of getting the same value if
they are chosen randomly; and - counter-intuitively - more if the server
supports >1 version because the middlebox needs to make connections in all
possible versions.

The state a middlebox needs to commit to remembering all salt values is
pretty high - assuming that the entire space is covered. This is in the
order of 2^36 bytes if we insist on a 16 byte salt, though we might
reasonably insist on longer salts. Our current salt is 20 bytes, and 32
byte salt is no more expensive to compute or produce with HKDF-SHA256, so
we could probably go that high.

So I think that this is a good change, the best we can do in our current
state. I do think that it needs a little more text about the operation of
this mechanism, and we still need to sort out the lifetime thing, but it's
pretty good. I might propose some text amendments.

This might be better attached to NEW_TOKEN, which corresponds more closely
with connection establishment patterns. A transport parameter is simpler,
but the use of a version number will link sessions, so you can't
realistically use a fake version over multiple connections. That suggests
to me that altering NEW_TOKEN is better than what is proposed.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 08 Apr 2019 18:07:46 -0400

> Should we consider a longer version number to reduce the chance of odd 

Not sure what sort of conflict you are talking about, but if you are talking about reducing the odds of collision to something trivial, then we're probably talking 128 bit version numbers.  That starts to get unwieldy, and there are plenty of other ways in which this scheme fails before then.  32 isn't terrible and has the advantage of not having to re-open the patient.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 8 Apr 2019 15:54:55 -0700

> Not sure what sort of conflict you are talking about, but if you are talking about reducing the odds of collision to something trivial, then we're probably talking 128 bit version numbers.  That st…

In practice, the "alt version" will have to be stored the same way
server specific data is stored -- new token, session resume token, etc.
That means specific to an SNI and possibly ALPN. But then we get a 32
bit token largely unique to an SNI, which does not play too well with
SNI encryption.

Unless of course version greasing is coordinated with SNI encryption.
There will not be leakage if services that share the same fronting
server select the same version number grease and salt. But then we have
to consider what to do for services that hide behind several fronting
servers, such as multiple CDN. It seems complicated.

-- Christian Huitema

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 8 Apr 2019 19:30:38 -0700

I like the mechanism quite a bit, and I agree with Martin's comment. I'll
note that the lifetime is critical for us to be able to deploy newer
versions, and I think the lifetime details are important to work out.

I also like the idea of _not_ sending this in transport params but in a
frame later.  While I understand that it might go in the same store, the
lifetime of this thing might be quite different to the address validation
token. The considerations for the lifetime of address validation tokens
have to do with rotation times for those keys, where a server could
reasonably much longer lifetimes for versions. Unless there's an argument
that they should be the same, I'd rather not tie the lifetimes of version
selection and address validation.  Instead of NEW_TOKEN, we could use a
separate NEW_VERSION frame, to keep them semantically separate.

Martin: I don't understand what you mean by "supporting the version as long
as QUIC is supported". Also, a middlebox can force a version negotiation,
how does it force a Retry?

On Mon, Apr 8, 2019 at 3:56 PM Christian Huitema <[email-masked]>
wrote:

> > Not sure what sort of conflict you are talking about, but if you are
> talking about reducing the odds of collision to something trivial, then
> we're probably talking 128 bit version numbers.  That starts to get
> unwieldy, and there are plenty of other ways in which this scheme fails
> before then.  32 isn't terrible and has the advantage of not having to
> re-open the patient.
>

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 8 Apr 2019 19:38:55 -0700

Christian: It seems to me that you could co-ordinate greasing with eSNI.
Can you say more about what gets complicated with multiple fronting servers?

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 9 Apr 2019 12:26:34 +0900

> The question of whether retrying is necessary is an interesting one that we might want to take up before we conclude this.  I tend to think that as long as this mechanism comes with a commitment to…

Correct me if I'm missing something, but my view is that retry (i.e.
fallback to v1) is necessary.

Not requiring retry means that a server cannot forget the randomized
version number. As you state, a server can use a PRF to calculate the
version number. But even in such case, a server needs to retain the
static key being fed to the PRF. If the server loses the static key,
clients would fail to reestablish connections.

This is kind of a requirement that we have not had. In TLS (or the
current draft of QUIC), it is possible to setup a new server just by
generating a new private key and by obtaining a new certificate. No
"persistent state" is required for running a server. Note also that we
would not be able to switch to a different server that uses a
different PRF.

Going back to the discussion of the proposed approach in general, I
think that it is a good idea.

At the same time, I have a fear that trying to make this part of v1
might slow down the standardization process. Can't it be a v1
extension, considering the fact that the intent is to grease, and
greasing works if only _some_ of the implementations support the
feature?

Until v1 gets finalized, we will be effectively greasing the version
number field by exchanging private (Chromium) and experimental version
numbers (0xffffffxx). Assuming that we can create a stable WG I-D of a
greasing proposal by the time v1 gets finalized, we will have the room
to continue running multiple versions.

Another benefit of defining it as an extension is that it could have
tighter requirements, such as requiring the server to retain
persistent state.

-- 
Kazuho Oku

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 08 Apr 2019 23:36:56 -0400

On Tue, Apr 9, 2019, at 12:31, Jana Iyengar wrote:
> Martin: I don't understand what you mean by "supporting the version as 
> long as QUIC is supported". Also, a middlebox can force a version 
> negotiation, how does it force a Retry?

I was being imprecise.  I'm not talking about Retry, I'm talking about the client starting over with 0x1 rather than the aliased version.  It's clear that an attacker can force a downgrade to TCP as long as you are willing to do that, but what I want to avoid is allowing an attacker to force a client to attempt another connection with version=0x00000001.  If the alias comes with a commitment that says if 0xALIASEDV doesn't work, then 0x00000001 won't work either, then I think we're in a better place than we would be if we encouraged clients to fall back to 0x00000001.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 08 Apr 2019 23:44:41 -0400

> clients would fail to reestablish connections.

There is no obligation on the server to advertise a non-zero lifetime for this.  If a deployment doesn't want to maintain a static key (which might be the same one that is used for stateless reset), then they don't have to.
 
> greasing works if only _some_ of the implementations support the

Yes, this works pretty well as an extension.  It works less well as a NEW_TOKEN addition, so there is some value to doing it now.

> to continue running multiple versions.

I'd like to eliminate the private use range, which I think is consistent with this design.  After all, you only need to avoid collisions and the space is huge.

(Note that it's possible to use alias to versions that have real semantics.  You just have to ensure that the alias isn't active when you start talking those versions properly.  We should discuss the consequences of that for middleboxes, but I tend to think that they turn out nicely in favour of the end to end model.)

---

From: Christian Huitema <[email-masked]>
Date: Mon, 8 Apr 2019 20:56:07 -0700

Jana,

If you are handling just one ESNI key, coordination is simple. Each
service could pick something like:

alt-version = (32 bits of) hash(ESNI public key, iteration number)

salt = (128 bits of) hash(ESNI public key, version number)

Since all the children know the ESNI public key, they all pick the same
set of version numbers for a given number of iterations, and outside
observers cannot derive the actual SNI from the version number. The salt
is somewhat predictable, but that's no worse than putting the salt value
in the QUIC-TLS draft.

Some services may be available behind multiple ESNI keys, maybe because
they can be accessed by multiple CDN. In that case, I suppose that they
can prepare different sets of version numbers for each ESNI key. Then,
when they see an incoming connection from a client, if they know which
ESNI key the client used, they can generate the appropriate version number.

So handling the scenario may be simpler than I thought. I hope I am not
overlooking a residual leak. In any case, we need to document the
relation between ESNI and greasing.

-- Christian

On 4/8/2019 7:38 PM, Jana Iyengar wrote:
> Christian: It seems to me that you could co-ordinate greasing with
> eSNI. Can you say more about what gets complicated with multiple
> fronting servers?
>
> On Mon, Apr 8, 2019 at 3:56 PM Christian Huitema <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     > Not sure what sort of conflict you are talking about, but if you
>     are talking about reducing the odds of collision to something
>     trivial, then we're probably talking 128 bit version numbers. 
>     That starts to get unwieldy, and there are plenty of other ways in
>     which this scheme fails before then.  32 isn't terrible and has
>     the advantage of not having to re-open the patient.
>

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 9 Apr 2019 12:57:54 +0900

> There is no obligation on the server to advertise a non-zero lifetime for this.  If a deployment doesn't want to maintain a static key (which might be the same one that is used for stateless reset)…

Yeah. My point is that any server-side deployment that tries to use
the feature will be required to retain something it can never forget
for the lifetime of the alias. Something being either a static key or
the alias versions themselves.

For mass-scale deployments, such a requirement might not be an issue.
Losing state is disastrous for them.

OTOH, for small-scale deployments (e.g., standalone servers), it is a
concern, because people often assume that they can try run a server,
scrap it, and then run another one, which has been the case for TCP
and TLS.

> Yes, this works pretty well as an extension.  It works less well as a NEW_TOKEN addition, so there is some value to doing it now.

That's a fair point. I agree that the version aliases should better be
carried by  the NEW_TOKEN frame (or within the token), though I think
that they should have it's own lifetime (due to the concern of server
losing state; not being able to use a token and not being able to
recognize a version alias have different consequences).

-- 
Kazuho Oku

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 8 Apr 2019 22:14:54 -0700

> scrap it, and then run another one, which has been the case for TCP

You're right that this is a new requirement/constraint, so we need to
articulate the implications clearly. That said, on this particular point, a
small deployment could just as easily choose to not advertise an alias if
it cannot guarantee that it will be able to remember the alias.

> > Yes, this works pretty well as an extension.  It works less well as a
> NEW_TOKEN addition, so there is some value to doing it now.
>

Yes, the lifetime difference is why I suggested using a NEW_VERSION frame.
That also aligns nicely with separating this as an extension.

---

From: Marten Seemann <[email-masked]>
Date: Tue, 9 Apr 2019 14:35:10 +0900

The problem with making this an extension is how clients would advertise
support for this extension.
Ideally, we'd avoid sending a transport parameter in the ClientHello,
otherwise middleboxes would be able inspect the ClientHello and block this
extension.

   1. If this alias versions are advertised in a transport parameter in the
   EncryptedExtensions, there wouldn't be any need to advertise support for
   this extension at all. Servers could just send the transport parameter, and
   clients would just skip over the unknown parameter if they don't support
   it. The downside of this approach is that the server is wasting bytes
   exactly when it's most constrained by congestion control and the
   amplification limit.
   2. A frame has the advantage that it can be sent at any time. However,
   we'd need an encrypted signal from the client that it is able to parse the
   VERSION_ALIAS frame, so we'd probably have to define a signaling frame that
   has to be sent by the client first.

In order to avoid this complexity I'd prefer to not make this an extension,
but part of the v1 spec.

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 9 Apr 2019 14:56:16 +0900

2019年4月9日(火) 14:35 Marten Seemann <[email-masked]>:
>
> The problem with making this an extension is how clients would advertise support for this extension.
> Ideally, we'd avoid sending a transport parameter in the ClientHello, otherwise middleboxes would be able inspect the ClientHello and block this extension.

I'm not sure if I agree with the framing.

If the threat model is middleboxes dropping Initial packets based on
the payload, the proposed approach is insufficient because it does not
hide the content of Initial packets. A middlebox can just
trial-decrypt the Initial packets using the v1 keys, then drop packets
that do not look like v1.

To rephrase, the proposal does not give us the freedom to circumvent
through middleboxes that check the payload, even though it prevents
middleboxes ossifying the version number field. Assuming that we agree
that the only intent is to prevent ossification, advertising the
capability using ClientHello TP seems fine to me.

PS. Yes, I am suggesting that we might want to consider using a
different encryption key for Initial packets, _if_ we agree that retry
(i.e. fallback to v1) is unnecessary.

> If this alias versions are advertised in a transport parameter in the EncryptedExtensions, there wouldn't be any need to advertise support for this extension at all. Servers could just send the transport parameter, and clients would just skip over the unknown parameter if they don't support it. The downside of this approach is that the server is wasting bytes exactly when it's most constrained by congestion control and the amplification limit.
> A frame has the advantage that it can be sent at any time. However, we'd need an encrypted signal from the client that it is able to parse the VERSION_ALIAS frame, so we'd probably have to define a signaling frame that has to be sent by the client first.
>
> In order to avoid this complexity I'd prefer to not make this an extension, but part of the v1 spec.
>
>> You're right that this is a new requirement/constraint, so we need to articulate the implications clearly. That said, on this particular point, a small deployment could just as easily choose to not advertise an alias if it cannot guarantee that it will be able to remember the alias.
>>
>> Yes, the lifetime difference is why I suggested using a NEW_VERSION frame. That also aligns nicely with separating this as an extension.

--
Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 9 Apr 2019 15:07:52 +0900

> (i.e. fallback to v1) is unnecessary.

My bad, I missed the fact that the PR already carries a salt.

And I think I might agree that we might want to have the feature
defined in v1. It's basically a non-issue for endpoints that are not
participating in the effort (i.e. clients ignore, servers do not
send).

I am still concerned about the possibility of the feature delaying the
standardization process, but we can land the proposal after we start
seeing the draft versions of QUIC being used in the wild.

-- 
Kazuho Oku

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 9 Apr 2019 12:09:22 -0700

Hm, perhaps I'm missing something. As an extension, the server would simply
advertise the alias in a transport parameter. A client that understands
this transport parameter could use it, others would not. Why does the
server need to know that the client understands and will use the new alias?
There need not be a requirement on a client to do it.

On Mon, Apr 8, 2019 at 11:08 PM Kazuho Oku <[email-masked]> wrote:

> > > If this alias versions are advertised in a transport parameter in the
> > > A frame has the advantage that it can be sent at any time. However,
> > >>> > Yes, this works pretty well as an extension.  It works less well
> as a NEW_TOKEN addition, so there is some value to doing it now.
> > >>>
> > >> Yes, the lifetime difference is why I suggested using a NEW_VERSION
> frame. That also aligns nicely with separating this as an extension.
> >
> >
> >
> > --
> > Kazuho Oku
>
>
>
> --
> Kazuho Oku
>

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 09 Apr 2019 22:34:52 -0400

On Wed, Apr 10, 2019, at 05:09, Jana Iyengar wrote:
> Hm, perhaps I'm missing something. As an extension, the server would 
> simply advertise the alias in a transport parameter. A client that 
> understands this transport parameter could use it, others would not. 
> Why does the server need to know that the client understands and will 
> use the new alias? There need not be a requirement on a client to do it.

There seems to be reasonable amounts of demand for a new frame, which would require that the client signal that it is willing to accept one.

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 10 Apr 2019 12:16:04 +0900

> There seems to be reasonable amounts of demand for a new frame, which would require that the client signal that it is willing to accept one.

Agreed. Though assuming that we'd use a frame for sending version
aliases, the trade-off is between:
* a) define the frame in v1
* b) define an extension, that suggests a client to use a TP to signal
it's support for the extension

where, a has the (potential) risk of delaying the standardization
process, b has the risk of middleboxes detecting and dropping
connection establishment attempts using the extension.

I do not think the downside of b is that important (because a
middlebox can simply block all the QUIC connections), but the risk in
a is also small. All in all, I think avoiding having an extension that
changes the behavior of QUIC stacks outweighs the risks.

And FWIW, I prefer extending the token for carrying the version alias
as MT suggests. Because that would allow the server to decipher the
correct version number from the contents of the token.

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 10 Apr 2019 04:13:33 +0000

Why not just dump the version+salt in TP as Jana suggests? A new frame was argued vs modifying another frame, but if you can do it all in TP, that is a void argument. Signalling in TP sounds over-complicated. Unlike NEW_TOKEN, you don’t have to wait for TLS to emit something.

________________________________
Fra: QUIC <[email-masked]> på vegne af Kazuho Oku <[email-masked]>
Sendt: onsdag, april 10, 2019 5:16 AM
Til: Martin Thomson
Cc: IETF QUIC WG
Emne: Re: Version Negotiation Greasing

2019年4月10日(水) 11:35 Martin Thomson <[email-masked]>:
> > use the new alias? There need not be a requirement on a client to do it..
>

--
Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 10 Apr 2019 13:30:40 +0900

2019年4月10日(水) 13:13 Mikkel Fahnøe Jørgensen <[email-masked]>:
>
> Why not just dump the version+salt in TP as Jana suggests?

I think Two reasons have been pointed out so far:
* Sending in TP reduces the amount of things a server can send in the
first flight (we are trying hard to fit the certificate chain in 3
packets; pointed out by Marten).
* Binding aliases to token let's servers issue different aliases for
each connection. Sending the aliases in TP would imply that they can
be used without a matching token. In such a design, it is impossible
to have different aliases for every connection (pointed out by MT).

> A new frame was argued vs modifying another frame, but if you can do it all in TP, that is a void argument. Signalling in TP sounds over-complicated. Unlike NEW_TOKEN, you don’t have to wait for TLS to emit something.
>
>

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 10 Apr 2019 04:34:54 +0000

Fair points. What if the connection goes down between new token and new version alias? Is the token usable in its own?

________________________________
Fra: Kazuho Oku <[email-masked]>
Sendt: onsdag, april 10, 2019 6:30 AM
Til: Mikkel Fahnøe Jørgensen
Cc: Martin Thomson; IETF QUIC WG
Emne: Re: Version Negotiation Greasing

--
Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 10 Apr 2019 13:38:18 +0900

2019年4月10日(水) 13:34 Mikkel Fahnøe Jørgensen <[email-masked]>:
>
> Fair points. What if the connection goes down between new token and new version alias?

Yeah. That's why I like MT's proposal to send a version alias as part
of a token.

> Is the token usable in its own?

My understanding is that version alias is proposed as an option, and
nobody is arguing against that. Assuming that is true, a token would
always be usable by its own.

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 9 Apr 2019 22:21:01 -0700

There is an argument floating that iff a client accepts the alias
extension, the alias must be used without the client attempting fallback to
the original version.

I’m not entirely sure what I think about this. It discourages middleboxes
from blocking anything but v1 but if a server park is not able to honor it,
or the client looses context, there is a problem. This problem can be
solved by tying the context to the token. But this means the token cannot
be used without the alias version. This in turn means that the token cannot
be valid until the alias has also been received. This  in turn introduces
race conditions that could have been avoided if the alias were in the same
frame as the token, or at least in the same packet (which is a
complication).

Mikkel

On 10 April 2019 at 06.38.30, Kazuho Oku ([email-masked]) wrote:

> > A new frame was argued vs modifying another frame, but if you can do it
all in TP, that is a void argument. Signalling in TP sounds
over-complicated. Unlike NEW_TOKEN, you don’t have to wait for TLS to emit
something.
> > > There seems to be reasonable amounts of demand for a new frame, which
would require that the client signal that it is willing to accept one.

-- 
Kazuho Oku

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 10 Apr 2019 13:04:20 +0000

HI all,

please see below.

On 10.04.19, 07:22, "QUIC on behalf of Mikkel Fahnøe Jørgensen" <[email-masked] on behalf of [email-masked]> wrote:

 >   There is an argument floating that iff a client accepts the alias extension, the alias must be used without the client attempting fallback to the original version.

Further thinking about this. I do understand that this requirement is needed to actually avoid blocking of alt-version, however, would anybody actually be ever willing to implement this? If you service does not get connectivity with the alt-version, is it not very tempting to also try the actual version in order to serve your user/customer at all?

Mirja

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 10 Apr 2019 21:29:20 -0400

On Wed, Apr 10, 2019, at 23:04, Mirja Kuehlewind wrote:
> Further thinking about this. I do understand that this requirement is 
> needed to actually avoid blocking of alt-version, however, would 
> anybody actually be ever willing to implement this? If you service does 
> not get connectivity with the alt-version, is it not very tempting to 
> also try the actual version in order to serve your user/customer at all?

The number of layers of fallback-and-retry that we maintain is already fairly terrible[1], so I suspect that we'll skip that step and fall straight back to h2.

[1] We don't want to add to happy eyeballs, alt-svc, network-level connection retries, the eventual parallel QUIC/h2 attempts, and HTTP request-level retries.

---

From: Ian Swett <[email-masked]>
Date: Fri, 12 Apr 2019 15:07:43 -0400

I'd prefer to see this as an extension, but it seems like an interesting
and useful proposal.

Adding a lifetime seems fairly critical in order to allow key rotation.

Originally I thought this belonged in NEW_TOKEN, but after further thinking
I think a new frame(ie: Jana's NEW_VERSION) or a transport param are both
fine.  A transport param is easier, so unless it has some unacceptable
technical issue(s), I'd be inclined to start with that and move to
something more complex as necessary.

I think removing the private use space to make this approach more feasible
makes sense to me.  It seemed like we were heading in that direction with
other proposals(ie: randomizing new version numbers).

On Wed, Apr 10, 2019 at 9:29 PM Martin Thomson <[email-masked]> wrote:

> The number of layers of fallback-and-retry that we maintain is already
> fairly terrible[1], so I suspect that we'll skip that step and fall
> straight back to h2.
>
> [1] We don't want to add to happy eyeballs, alt-svc, network-level
> connection retries, the eventual parallel QUIC/h2 attempts, and HTTP
> request-level retries.
>
>