Re: Going STEK-less with QUIC?

[Martin Duke <[e-mail]>]

I can't speak to the security concerns MT raised, but if we do use
NEW_CONNECTION_ID to populate the initial DCID in later connections, I *do*
think we need to write down this expectation somewhere, and QUIC-LB may be
as good a place as any.

1. How does the client know that the resumption state is local, and
therefore that it should use a previously provided connection ID?

2. A Retry would hopefully not divert this to a different server (but maybe
under Retry conditions killing resumptions is acceptable)

On Wed, Jul 28, 2021 at 10:08 AM Christian Huitema <[e-mail]>
wrote:

>
> On 7/27/2021 11:42 PM, Martin Thomson wrote:
> > On Wed, Jul 28, 2021, at 11:55, Christian Huitema wrote:
> >> [...] reuse one of the NEW TOKENS as Initial CID, [...]
> > Are you talking about NEW_CONNECTION_ID here?
>
> Yes. Sorry for the confusion. (Skipping comments on the progressive
> effect of aging on Christian's brain cells.) My initial idea was for
> creating an extension frame, with the server providing a new connection
> ID for the specific purpose of use in resumption of this connection. In
> a private message, Martin Duke suggested that clients could just as well
> use one of the NEW CONNECTION ID provided by the server. Clients can do
> that today, no change in spec required.
>
> > If you are talking about the client taking a connection ID from an old
> connection and using that when establishing a new connection, that's an
> interesting choice.  I don't think it works because it undermines the
> return routeability check for the subsequent connection.  The server now
> knows what the connection ID might be.  I can't think of an exploit for
> that given that the server has already demonstrated that it is on path, but
> we do pretty much say that the connection ID can't be predictable like
> that, and there are no firm requirements that the subsequent connection
> attempt follow the same network path in any way.
>
> I was not suggesting that placing a specific value in the ICID replaces
> the need for tokens and checking return routeability. Now, it is true
> that the servers and the load balancers could also coordinate their
> handling of token, and achieve the desired effect of sending connection
> resumption attempts to the same server as the original connection. That
> may very well be a better design than relying on the client to put
> specific values in the ICID.
>
> > I had assumed that the load balancer would be able to identify an
> initial and then route based on the Token field in that packet, rather than
> the connection ID.  Maybe that's too complicated, but it is something that
> could be used without protocol modifications.
>
> Yes. Looks like the way to go if we want to experiment with STEK-less.
>
> I think placing the NEW CONNECTION ID in an ICID has a different usage
> -- testing the robustness of load balancing...
>
> -- Christian Huitema
>
>
>