RE: Exercising Version Negotiation

["Lubashev, Igor" <[e-mail]>]

The easiest solution is the client sometimes trying a bogus version. It would be fully under client's control when to engage in such network policing.

-----Original Message-----
From: Ryan Hamilton [rch=[e-mail]]
Received: Thursday, 22 Mar 2018, 8:53PM
To: Mike Bishop [[e-mail]]
CC: Eric Rescorla [[e-mail]] IETF QUIC WG [[e-mail]]
Subject: Re: Exercising Version Negotiation

Agreed. As specified, I don't see how the server would be induced to send a version negotiation packet in this case. Ekr, perhaps you can provide some sample flows. If the server supports versions A and B, and the client supports versions A and B, then it doesn't matter which version the client prefers. In either case, the server supports the version the client is attempting to speak and will not send a version negotiation packet.

Further, it's complicated for the server to (some fraction of the time) send a VN packet in response to a connection attempt that uses a version the server actually does support. It will, obviously, need to exclude this version from the VN packet it sends to the client. That's easy. But it also needs to ensure that the list of QUIC versions it provides in the subsequent TLS handshake matches this version list. This, I suspect, is more complicated as version negotiation is typically stateless.

On Thu, Mar 22, 2018 at 8:46 AM, Mike Bishop <[e-mail]<mailto:[e-mail]>> wrote:
Technically, no, it wouldn't.  Servers accept if they're capable/willing to speak the version the client selected, so a server that supports both would always accept no matter what the client chooses.  You'd need the server to be contrarian a small percentage of the time instead.

From: QUIC <[e-mail]<mailto:[e-mail]>> On Behalf Of Eric Rescorla
Sent: Thursday, March 22, 2018 2:26 PM
To: Ryan Hamilton <[e-mail]<mailto:[e-mail]>>
Cc: IETF QUIC WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: Exercising Version Negotiation

It would exercise the former.

-Ekr


On Thu, Mar 22, 2018 at 2:10 PM, Ryan Hamilton <[e-mail]<mailto:[e-mail]>> wrote:
When you say Version Negotiation, do you mean the process of sending an receiving a version negotiation packet, or simply the act of speaking two different versions? Your proposal seems to be the latter but I don't think I follow how it would exercise the former, though maybe that's intentional?

On Thu, Mar 22, 2018 at 5:03 AM, Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:
Following up on the discussion at the mic, I do think it is useful to exercise the VN function, but I don't think it's useful to have those versions be different, because that creates perverse incentives.

Here's what I suggest instead: create two versions (we can call them QUIC v1+i  and QUIC v1-i), each with its own code point [0]. They should be essentially identical except for two trivial differences, intended to ensure that if you screw up version negotiation, you get failed interop.

- The constant in the handshake salt (5.2.2)
- The HKDF expansion constants

I suggest we handle each of these by just inverting the bits.

We would then suggest to people that they somewhat randomize their preferences (e.g., 99% of the time prefer v1+i, 1% of the time prefer v1-i). This will almost always result in matching versions, but will occasionally result in a mismatch, thus forcing us to test VN.

-Ekr

[0] Obviously we can do this for draft versions. We just say that the two versions are
ff0000XX and ffffffXX.