Marten Seemann

> Really? Isn't it possible to connect to a QUIC endpoint, receive their side of the handshake, then kill the connection before authenticating? There's the [Retry mechanism](https://www.rfc-editor.org/rfc/rfc9000.html#name-address-validation-using-re), which is designed...

That would imply that they've built special logic to identify QUIC connections. QUIC connections rotate their Connection IDs on a regular basis to make exactly that more difficult. What's the...

Interesting. And an impressive amount of research to locate the problem. Have you ever tried getting in touch with Free Mobile? This very much sounds like a problem on their...

@BigLep Have you had the chance to look at this PR?

> Implement the proposed TLS1.3 PSK extension: https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-00. This allows mixing the pre-shared key with the result from the handshake. We're in the unfortunate situation where the Go team effectively...

There's not been any progress in Go's standard library TLS implementation, which we'd need to mix in symmetric keys. Is there a third option here? Can we do the encryption...

This might be a crazy idea. What about *only* encrypting the certificate (or the libp2p extension in the certificate)?

Another option would be to *only* encrypt Handshake packets. Let me explain: QUIC uses different packet types during the Handshake: - Initial packets carry the ClientHello and ServerHello. They're obfuscated,...

@Stebalien, @Kubuxu How can we move forward with this issue? Looks like we have a few different options, each with its pros and cons, and we need to make a...

Copying from Slack. @raulk raised the following point: > The problem with encrypting _only_ the certificate is that if I happen to get access to a node’s private TLS key...