Hello Tor Project team, I’d like to propose work on two pluggable-transport (PT) approaches that are under-represented and promising for censorship-resistant connectivity: 1. DNS-over-HTTPS (DoH) — lightweight bootstrap/control channel 2. gRPC over HTTP/2 — medium-bandwidth API-style cover as an alternate path Summary / motivation - DoH is already ubiquitous for resolver traffic and makes an excellent low-bandwidth, hard-to-block bootstrap or handshake channel if its TLS and HTTP semantics are convincingly matched. - gRPC over HTTP/2 approximates modern microservice API traffic: it supports binary protobufs, multiplexing, and request patterns that could plausibly hide Tor control or medium-bandwidth traffic when implemented correctly. What needs to be matched (technical fingerprint checklist) DoH (bootstrap/control) - Proper HTTP semantics: GET vs POST usage, request URLs, query parameters, Content-Type: application/dns-message. - TLS ClientHello profile: cipher suites, extensions, and ordering that match real DoH clients. - Resolver behaviour: realistic query timing, distribution of queried names, EDNS padding patterns, caching/TTL behaviour. - Endpoint selection: plausible resolver IPs or cooperating resolvers; avoid impersonating a single provider verbatim. gRPC over HTTP/2 - Correct HTTP/2 SETTINGS and initial frame ordering, window sizes, and flow control behavior. - HPACK header ordering and dynamic table behaviour consistent with real clients. - content-type: application/grpc framing (5-byte prefix) and protobuf payload size/patterns. - Multiplexing and concurrent stream lifetimes that match typical microservice usage. - TLS+ALPN indicating h2 and realistic client TLS fingerprints. High-level design suggestion - Hybrid approach: implement gRPC/HTTP2 as the main data channel; use DoH as a minimal, stealthy bootstrap/handshake channel. - Prototype in stages: DoH is lower complexity and valuable for learning how strict TLS/HTTP fingerprints must be. gRPC/HTTP2 can be tackled next for medium-bandwidth traffic. - Testing: capture real traces from modern browsers/clients and create behaviour models (packet sizes, timings, SETTINGS sequences) to drive deterministic emulation. Validate against both signature-based DPI and ML flow detectors. - Ethical/legal: avoid impersonating a specific cloud provider or critical service verbatim. Prefer “class” mimicry (generic HTTPS/API behaviour) or cooperative fronting partners. Test only in controlled environments and with clear user consent. Risks & caveats - Censors increasingly use ML/flow analysis; simple header/TLS mimicry is insufficient — flow-level statistics must be matched. - Impersonating major cloud providers/resolvers can create legal or service-impact risks; this requires careful consideration and preferably cooperation. Requested next steps 1. Is the Tor Project interested in exploring DoH and/or gRPC/HTTP2 as new pluggable transports? 2. If yes, would you prefer a short design doc + sample traces (DoH first), or should I open a GitHub issue with a proposed roadmap and prototype tasks? 3. Are there legal/ethical constraints I should be aware of when proposing specific endpoint classes (e.g., cooperating CDN vs. impersonation)? Thank you for considering this. I’m happy to iterate on the proposal, provide technical traces, or collaborate on a prototype. Best regards, Kes Pembroke This email pembrokekester80@gmail.com