Subject: Changes to the connection id negotiation in -02

From: Subodh Iyengar <[email-masked]>
Date: Thu, 30 Mar 2017 17:33:07 +0000

In the WG meeting @Jana went though some changes which allowed a server to choose connection id.

The exact text in the draft seems to be "When a connection is initiated, the client MUST choose a random value and use it as the initial Connection ID until the final value is available. The initial Connection ID is a suggestion to the server. The server echoes this value in all packets until the handshake is successful".

I can see the security reasons to require the client to switch to the server chosen id only after the handshake is successful, however I think it interacts poorly with stateless rejects.

When a server wants to do a stateless reject of the client due to DoS concerns or any other reasons, it does this via a HelloRetryRequest in the TLS layer. At this point a server might want to choose a connection id to send to the client so that it can choose an alternative backend it wants to direct the client to. Since the HRR does not mean that the handshake is successful, the client will keep using the original connection id it and not respect the server's choice of backend.

@Lubashev, Igor<mailto:[email-masked]> also brought up during offline discussions that this is the same for version negotiation as well in case there are separate backend servers that support different versions. He also brought up that it creates an ambiguity at a load balancer of whether it is using the client chosen connection id or a server chosen one.

The simplest alternative to change this to is something like: "In its first flight, the client MUST not use any connection id, and should latch on to the first connection id that the server sends", even before the handshake is complete

However this means that the first flight would be routed by 5 tuple and if a NAT rebinding occurs in the first flight that would cause the connection to fail. Alternatively we could just allow clients to advertise their id, but latch on to a server id as soon as they have one.

It seems like it comes down to whether there was a major security rationale for only binding connection id after the handshake was successful.

Subodh