View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011263 | GNUnet | transport service | public | 2026-03-19 12:23 | 2026-03-19 12:27 |
| Reporter | schanzen | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | have not tried |
| Status | new | Resolution | open | ||
| Target Version | 1.0.0 | ||||
| Summary | 0011263: QUIC+TLS+ECH Communicator | ||||
| Description | Our current two QUIC/HTTP3 communicators should be consolidated into a single QUIC communicator. That communicator should speak QUIC (https://datatracker.ietf.org/doc/html/rfc9000) TLS 1.3 (https://datatracker.ietf.org/doc/html/rfc8446) with ECH (https://datatracker.ietf.org/doc/rfc9849/) That should be our transport and security baseline for GNUnet communication. Libraries: QUIC+TLS: https://github.com/ngtcp2/ngtcp2 For ECH, the OpenSSL backend of ngtcp2 can be used, ECH is support on OpenSSL >4.0 Maybe introducing a different TLS dependency can facilitate integration speed, as OpenSSL major version bumps in OSes take time. | ||||
| Tags | No tags attached. | ||||
|
|
Example client and server ECH configuration of OpenSSL: https://github.com/openssl/openssl/blob/master/demos/sslecho/echecho.c How to get OpenSSL context handle in ngtcp2: https://github.com/ngtcp2/ngtcp2/blob/main/examples/tls_client_session_ossl.cc |
|
|
It is necessary to convert the HELLOs we know (in particular the EdDSA keys) into something that can be used in the ECH (see RFC9849). This should be straight forward. Then we need to figure out which key to use for the TLS handshake (or rather the key used in the presented certificate). We could design a HELLO that encodes another key in the HELLO that serves as the certificate key or the HPKE key for the ECH. It would probably make more sense to encode the ECH key, as it needs to be X25519 (not EdDSA), and the EdDSA can be naturally used in TLS self-signed certs. |
