Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TLS QUIC Transport Parameter For Retry SCID #1221

Open
BiagioFesta opened this issue Apr 28, 2022 · 1 comment
Open

TLS QUIC Transport Parameter For Retry SCID #1221

BiagioFesta opened this issue Apr 28, 2022 · 1 comment

Comments

@BiagioFesta
Copy link
Contributor

From RFC 9000#7.3, the scenario is:

Client                                                  Server

   Initial: DCID=S1, SCID=C1 ->
                                       <- Retry: DCID=C1, SCID=S2
   Initial: DCID=S2, SCID=C1 ->
                                     <- Initial: DCID=C1, SCID=S3
                                ...

The important point here is the fact that server changes SCID on its INITIAL after retry, (see Initial: DCID=C1, SCID=S3).

However, it seems the HANDSHAKE packet afterwards generated by the server does not correctly populate the quic transport parameter. In particular, the retry_source_connection_id (0x10).

That field should contain the SCID used in the RETRY packet (from the example above would be S2).

Instead, in quiche code seems that field is always populated with the SCID build for the INITIAL packet (in the example would be S3): here -today mainline commit-.


If I am not wrong, this will make all handshakes fail because of this check on the client side (which comes from the RFC9000#7.3).

The only workarounds I see (with possible drawbacks) are:

  • Do not perform RETRY mechanism. This makes denial of service attacks easier tho.
  • Do not change SCID during RETRY/INITIAL (that is having S2 == S3).
    • Essentially, this is what has been made in the example of this repo example/server.rs.
    • I am not sure if there are security implications into having S2 == S3 and whether it's fine keeping the same connection id.

Is this a known limitation or am I missing something else?

@ljluestc
Copy link

// This is a simplified and illustrative example.
impl Connection {
    fn handle_retry(&mut self, retry_packet: &RetryPacket) {
        // Store the SCID from the RETRY packet
        self.retry_source_connection_id = retry_packet.scid.clone();
    }
    
    fn generate_initial_packet(&self) -> InitialPacket {
        let mut initial_packet = InitialPacket::new();
        
        // Ensure retry_source_connection_id is set correctly
        initial_packet.retry_source_connection_id = self.retry_source_connection_id.clone();
        
        initial_packet
    }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants