IETF Logo Mail Archive

[TLS] Re: ECH Proxy Mode

Christopher Patton <cpatton@cloudflare.com> Fri, 06 September 2024 23:42 UTC

Return-Path: <cpatton@cloudflare.com>
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 2073AC1519AB for <tls@ietfa.amsl.com>; Fri, 6 Sep 2024 16:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.705
X-Spam-Level:
X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=cloudflare.com
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 S-o6FRJGsqB0 for <tls@ietfa.amsl.com>; Fri, 6 Sep 2024 16:42:05 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6598FC151070 for <tls@ietf.org>; Fri, 6 Sep 2024 16:42:05 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id d75a77b69052e-456850b370eso16197131cf.1 for <tls@ietf.org>; Fri, 06 Sep 2024 16:42:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1725666124; x=1726270924; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3VhhQu/eBRtV6h6uB3xxeB5I08wwvfWT7o4n9qPWp5c=; b=WrWa69Lpp4tozMWIJONkGcLx34BaJUtK5kTrrvyHP/NwvJNgPla/gNySkLXERgex/s j/fNZyhWfeW1jfGH7TTZa/LDwYmYT7UCRqCx7AcZMQQy7hfVSd7trilR5iE9tY80ftCB 2NPnuLJqvdY6ZmMiOG4KezmK6LFVpDzOZdTt6VMTzud4OLauRBPEsGr0nOP7qQfnktBo sw8BIVMy4UUTR4UYteUEhiO9sof5Em1BukZGy7Dnc2cN+URKaDzMvzvZyGaUj8KkjKUn /k208MK0t9AGGDA+uzLno17ErSAEqyqM3HarAwxasTpV9INW9d021qqZxwvctkbJNIal eULQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725666124; x=1726270924; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3VhhQu/eBRtV6h6uB3xxeB5I08wwvfWT7o4n9qPWp5c=; b=OyDC1VhxLGX2/m3wNc8tNX7ubZK9qjLdHVjfBlUd4+xNysgxfISaAlHqUPmvTAPnHt KpeI3IT49NQOnhA/k9o6oqyhi55HPrTfQVObt6WwLGLbsriAWVvuzblXiz9vswu0i9U9 eCBkrXe59Jidc7xUetS6F6xYrIHO/uuXvW9+KwrNTGMUdlEEDrMhDHzD6jz0tP5s+odH c8Tn6jG+ihm0aSuF4u2EpriLnrvJWLET8mQdWt6j9gfjEUkJgCxnHMv9Y3j3hkFse6QG pDBEOd29GI7SKTu4E6j4n3/faZX4SdLaAKb459r26sGH8t59e3bdrHc+/LCbgp/rA1b1 oyhA==
X-Gm-Message-State: AOJu0YwKxC1WTptO4zYxGw/epWE+gv0rot06sJ+XFv2fUT3f+IX2pHkY IJQCVfhI+xhJ9kLQoFoV9EVWkxmcIIp3wOfQZFey0Xwa04qm2qU6s5d9ICveNdGgQdQuQmtwV2F alziANWigM7sXBpVEn8mWeLhHoR5H+lgboiIpTzUZ9Gz2OqkPCLDOcg==
X-Google-Smtp-Source: AGHT+IGUCl1BsRKt5Un1UMz58tiWEwbH9J7MUa7ho2n9zVRhmEAFHuM7XRjGbbriDG7TWOv+1nBX4LCTTGcKouDtsrU=
X-Received: by 2002:a05:622a:1496:b0:456:802c:a67f with SMTP id d75a77b69052e-4580c67091dmr39807061cf.3.1725666123923; Fri, 06 Sep 2024 16:42:03 -0700 (PDT)
MIME-Version: 1.0
References: <03D6DC16-2AFE-41E8-8404-F456D67582EB@taoshu.in>
In-Reply-To: <03D6DC16-2AFE-41E8-8404-F456D67582EB@taoshu.in>
From: Christopher Patton <cpatton@cloudflare.com>
Date: Fri, 06 Sep 2024 16:41:53 -0700
Message-ID: <CAG2Zi211eXC0HESM3NFyk89a5a=G6pM50wDbTUud6nC_UMrD9g@mail.gmail.com>
To: 涛叔 <hi=40taoshu.in@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005160b806217bf486"
Message-ID-Hash: CRN2QD2EGDN5MT4EMN3JCS4OPQXRSNZR
X-Message-ID-Hash: CRN2QD2EGDN5MT4EMN3JCS4OPQXRSNZR
X-MailFrom: cpatton@cloudflare.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: tls@ietf.org
X-Mailman-Version: 3.3.9rc4
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/Jpr7fOa8IpIHRlhFnpHpBMz9rhM>
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>

> So is it possible to transfer the accept_confirmation in some plain text
> extensions
> like Key Share, or other dedicated extension?
>

Just a historical note here: the acceptance signal was designed this way so
that the client has an explicit signal of whether the server used the inner
ClientHello (CH) or the outer CH. Further, we decided that the signal
shouldn't be an extension due to the risk of middleboxes doing something
weird with it. We call this "sticking out". See
https://github.com/tlswg/draft-ietf-tls-esni/issues/274 for the initial(?)
discussion.


This idea was derived from my attempt to implement encrypted TLS SNI Proxy.
> The SNI
> does not only expose privacy information, many ISP use it to block certain
> web site.
> Even though the current draft of ECH works to protect the ClientHello, it
> can only
> protect the sites that deployed the ECH.
>

Your suggestion reminds me of Option (2) in that issue. See Nick's point
here:
https://github.com/tlswg/draft-ietf-tls-esni/issues/274#issuecomment-677851703
However, see David's comment here:
https://github.com/tlswg/draft-ietf-tls-esni/issues/274#issuecomment-677893312

Chris P.

v2.27.8 | Report a Bug | By Email | System Status