[TLS] Re: ECH Proxy Mode
Naomi Kirby <naomi-dev@manawolf.ca> Sun, 15 December 2024 19:44 UTC
Return-Path: <naomi-dev@manawolf.ca>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82004C151556 for <tls@ietfa.amsl.com>; Sun, 15 Dec 2024 11:44:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manawolf.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMsu2yaMF2yi for <tls@ietfa.amsl.com>; Sun, 15 Dec 2024 11:44:22 -0800 (PST)
Received: from mail-4018.proton.ch (mail-4018.proton.ch [185.70.40.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4DDEC14F702 for <tls@ietf.org>; Sun, 15 Dec 2024 11:44:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manawolf.ca; s=protonmail; t=1734291858; x=1734551058; bh=t/pQVEI7Oc2MXq7jpr07E2Rj4R3+n6Bi8ZzPY5HvbPk=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=SvJQvvYsuYDQhrJt0Ro7KHqMJcT1j/L+MwfraiDD59Kkio+LoOVTnuHcq4C64z1/n hunkCGuWk539VtCCsD6lpGIXTV2wMn4M9GRZ76kUHrW1w1HcfoE5PggBs7eQn9CfUy PXu8mkxXxqsJEn8/1jQjwp+WiGJ262TAnzeGFxa15WrbY5fQKllBjp2uaBWjeEqoB4 c149d5Zkk0rcTSX5HbQ6yzcR5JkNsecwaatEXubrxg80IF/RAreBDEIwmfHiBQZEdZ gDFdKNIsOL4m/HY23IYZUN58oshu4cMlnbkbXMiBe7AB4raD1mxqDa4LWHF+Aaiq/Q 8+0uT3FFK+McQ==
To: "tls@ietf.org" <tls@ietf.org>
From: Naomi Kirby <naomi-dev@manawolf.ca>
Message-ID: <GHHVv77sDOPuEUAz-jHqK2Oq4cx_qc3d4PsxOFV4hOBj1aIR3cZiZ64BMF1fQYuGTUmMx6CND_bgJ6vO5Y4bOS2hhRQESFNe3kWTHBAL2JE=@manawolf.ca>
Feedback-ID: 90389954:user:proton
X-Pm-Message-ID: 7863e81db6639e8500581fd8c332b82816a6c312
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-MailFrom: naomi-dev@manawolf.ca
X-Mailman-Rule-Hits: nonmember-moderation
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0
Message-ID-Hash: DUKH5GYNMQXH6GKZTLNTJJMB5VBPWDGW
X-Message-ID-Hash: DUKH5GYNMQXH6GKZTLNTJJMB5VBPWDGW
X-Mailman-Approved-At: Mon, 16 Dec 2024 07:13:45 -0800
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: ECH Proxy Mode
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Uae8NVvo7eXf-oZcP8uKzSb8qQU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>
Date: Sun, 15 Dec 2024 19:51:55 -0000
X-Original-Date: Sun, 15 Dec 2024 19:44:13 +0000
Hey everyone, I just wanted to chime in and mention that I am also disappointed that split-mode ECH can't be implemented without the backend server being ECH aware, and this has prevented me from deploying ECH on my network. I have a small homelab of servers that I run behind a reverse proxy, which uses the SNI extensions to direct inbound connections to the backend server, and I have wildcard DNS records setup to direct all subdomains on my network to the reverse proxy. It works great, I don't have to touch my DNS provider to add new services, but it does leak the serer names to an eavesdropper. So, I was hoping to upgrade the reverse proxy to support ECH, I was hoping that I could add an ECH record and have the reverse proxy decrypt the ClientHelloInner and forward it off to the backend server. Unfortunately, this doesn't work if the backend server doesn't support ECH as it won't know that it needs to generate the accept_confirmation and the client will mistakenly think that the handshake is proceeding with the ClientHelloOuter even if the proxy can decrypt the ClientHelloInner just fine. I'm sure I could make this work anyways, either by adding exceptions for the backends that don't support ECH or having the reverse proxy terminate the TLS connections. But I am disappointed that I couldn't realize the privacy gains of ECH without having to upgrade the backend servers first. Anyways, thank you for all the effort put into this draft, it's a great step forward for privacy. Thanks, Naomi
- [TLS] Re: ECH Proxy Mode Raghu Saxena
- [TLS] Re: ECH Proxy Mode 涛叔
- [TLS] Re: ECH Proxy Mode Christopher Patton
- [TLS] Re: ECH Proxy Mode Raghu Saxena
- [TLS] Re: ECH Proxy Mode 涛叔
- [TLS] Re: ECH Proxy Mode Raghu Saxena
- [TLS] Re: ECH Proxy Mode 涛叔
- [TLS] Re: ECH Proxy Mode A A
- [TLS] Re: ECH Proxy Mode 涛叔
- [TLS] Re: ECH Proxy Mode A A
- [TLS] Re: ECH Proxy Mode Naomi Kirby
- [TLS] ECH Proxy Mode 涛叔
- [TLS] Re: ECH Proxy Mode A A