Re: Exercising Version Negotiation

[Eric Rescorla <[e-mail]>]

On Thu, Mar 22, 2018 at 8:53 PM, Ryan Hamilton <[e-mail]> wrote:

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

I'm not suggesting that you flip the preferences, but rather that the each
side configure itself with one version for a given connection. This is
obviously trivial for a client. For the server, you can just hash the
client's IP address to get a stable choice.

-Ekr



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]> 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]> *On Behalf Of * Eric Rescorla
>> *Sent:* Thursday, March 22, 2018 2:26 PM
>> *To:* Ryan Hamilton <[e-mail]>
>> *Cc:* IETF QUIC WG <[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]> 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]> 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>