Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)

[Martin Thomson <[e-mail]>]

In the interests of both providing defense in depth and for simplifying the analysis of the protocol, I believe that we should consider the ways in which connection IDs are negotiated and the ways in which that negotiation might be more strongly protected.

## Problem Statement

We currently do not validate any choice of any connection ID that is chosen during the handshake, with the exception of the Destination Connection ID the client chooses when a Retry was used.

The [paper above](https://eprint.iacr.org/2020/114) describes an attack on earlier versions of header protection that relied on the variable position of the packet number length field, the lack of an authenticated length of the connection ID, and the malleability of the encryption used in header protection.  We have since fixed the position of the packet number length, which invalidates that attack.  The effect of the attack was not severe, but I would rather not have any weaknesses.  Note also that two of these weaknesses remain and we only really fixed this problem by accident.

The attack described required that a server generate a Retry.  The attacker rewrites the Source Connection ID field from that message into a value that the server would then subsequently reuse.  This seems to be in tension with the requirement that connection IDs be unpredictable, but I believe the theory is that the requirement only applies to the question of linkability.  As long as an attacker is unable to generate another valid connection ID or link valid connection IDs to this original value, a server could reuse the client's choice.  Of course, in this case the value is chosen by the attacker, not the client.

A server could authenticate the value it includes in a Retry packet by including it in the token, but let's assume for now that it does not do that.  Whether or not there is a concrete attack out of this, this demonstrates that an attacker can choose a connection ID.  That's not a great position to be in with respect to analysis of the protocol.

Right now the values that are negotiated using the Source Connection ID field are not authenticated.  It is true that these are ultimately authenticated when they are included in the AAD of a 1-RTT packet, but that is rather circuitous. You might also say that Handshake packets also cover these, but that relies on even more convoluted logic. What I heard at QUIPS and what I learned from TLS is that formalizing proofs based on such indirect authentication can be extremely challenging.  I realize that this is theoretical, but we made concessions in TLS for simplified analysis and as long as the complexity cost is low, the same might be done here.

## Proposal

A relatively simple way to authenticate these connection IDs would be to include a `handshake_connection_id` transport parameter that includes the value that the endpoint includes in the Source Connection ID field of Initial or Handshake packets.  Endpoints then validate this value before declaring the handshake complete.  In terms of transport parameter construction, this is simple: endpoints make a choice and stick with it.  The only real cost is the extra 21 bytes this takes.

That isn't quite enough though.  The server gets to choose new connection IDs twice during the handshake if a Retry packet is sent.  Authenticating a single connection ID could not authenticate the Source Connection ID from the Retry packet.  That's might be OK on the basis that the value from the Retry won't be used after the handshake completes.

Not authenticating the choice from Retry is less OK if the server adopts the value that the client uses in its Destination Connection ID field.  Now the attacker just chose a connection ID.  As this was the specific attack that was used, that needs to be addressed too.

Rather than authenticate the Retry also, my suggestion there is to forbid the server from copying the client's Destination Connection ID when it generates its first Initial packet.  That is, the server needs to pick a completely new connection ID.  We already do that for Retry packets.  Then the attacker has no input into connection ID selection.

We could limit the requirement to change connection ID to only the cases where Retry is used.  That is require a change if there is a token in the Initial packet.  It seems easier to require the change always.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3439#issuecomment-594320754