Re: [TLS] Possible blocking of Encrypted SNI extension in China
David Fifield <david@bamsoftware.com> Sun, 09 August 2020 15:35 UTC
Return-Path: <david@bamsoftware.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 F1F243A0D03 for <tls@ietfa.amsl.com>; Sun, 9 Aug 2020 08:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bamsoftware.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBXzMMvRRp3w for <tls@ietfa.amsl.com>; Sun, 9 Aug 2020 08:35:30 -0700 (PDT)
Received: from melchior.bamsoftware.com (melchior.bamsoftware.com [IPv6:2600:3c00:e000:128:de39:20ee:9704:752d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E2F3A0CE1 for <tls@ietf.org>; Sun, 9 Aug 2020 08:35:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bamsoftware.com; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=DQdlFWQNULU4tNjsHKs/4SH35AG+W5Pb/81jQG4Xptg=; b=Ik0cyTooc8wP05om6GTgLVLGrQ SuDlTa7JL0uv8touOBDeHR8btjraO2Wd8CBoZetZZ8d/8W1byBzNjYmQU7+DT3Aa2a7mc/XuqtZw5 xhgM6+JhX5eXGPd1KtSPV+d9bgO17AEEVbVr/VN1N/29KmpzSaxM/RjawOKHp54u6xEI=;
Date: Sun, 09 Aug 2020 09:35:26 -0600
From: David Fifield <david@bamsoftware.com>
To: tls@ietf.org
Message-ID: <20200809153526.vf5zlongieoswb22@bamsoftware.com>
Mail-Followup-To: tls@ietf.org
References: <uGJxvVQRPcgn2GZKsKuuVN4SyTe7EOiV3iEK3Cq3Izo0ZstAh1LxEzMKrDZ_0VTrLqeYXQb4k1Qy5uJmEy04zNgngoHBONhVZnvddYYybt8=@iyouport.org> <71e4d18d-9ad8-fd72-729c-db5a0cf7593b@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <71e4d18d-9ad8-fd72-729c-db5a0cf7593b@huitema.net>
User-Agent: NeoMutt/20180716
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2X4ciX8rDkQp5eDmt170OuHr6JI>
Subject: Re: [TLS] Possible blocking of Encrypted SNI extension in China
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Aug 2020 15:35:41 -0000
On Thu, Jul 30, 2020 at 11:16:50AM -0700, Christian Huitema wrote: > Thanks for the report. I think this relates to our ambivalence about the > requirement for ESNI to not "stick out". That requirement is hard to > meet, and designs have drifted towards an acceptation that it is OK to > stick out as long as a sufficiently large share of the traffic does it. > If that share is large, goes the reasoning, it would be too costly for > censors to just "drop everything that looks like ESNI". Well, given > actors like the Great Firewall, one wonders. There's nothing wrong with that reasoning, in my opinion. To blend in with a crowd, you can change yourself to match the crowd; or you can change the crowd to match yourself. My feeling is that ESNI is currently easy to block (or to put it in terms I like, *inexpensive* to block) because very few TLS connections use it--nothing valuable depends on it yet. Whereas if encrypted SNI were somehow deployed suddenly and massively such that it became a normal feature of TLS connections both essential and inessential, it would be more difficult (read: expensive) to block. After all, even the GFW is not all-powerful. Surely it would prefer to abolish TLS altogether, but it's too late for that. At this point, blocking TLS would cost too much--not in terms of implementing firewall rules, but in how much essential communication it would damage. Put another way, the GFW itself, and the people who operate/manage it, would feel some of the pain of blocking. I don't mean to imply that coordinated deployment is the only path to success, just saying that if SNI encryption were already widespread, even an obvious tag like 0xffce would not be a useful distinguisher. And though I find it useful to think of these things in terms of the costs of overblocking, it's not an infallible guide. A large organization like the GFW is made up of many conflicting motivations, and it is as prone as any other to making bad decisions and enacting policies that are evidently against its own interests. For that reason I believe it's possible to reduce the risk surrounding the deployment of encrypted SNI, but not eliminate it completely.
- [TLS] Possible blocking of Encrypted SNI extensio… onoketa
- Re: [TLS] Possible blocking of Encrypted SNI exte… Christian Huitema
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Possible blocking of Encrypted SNI exte… Dmitry Belyavsky
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Christian Huitema
- Re: [TLS] Possible blocking of Encrypted SNI exte… Christopher Wood
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… Salz, Rich
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Christian Huitema
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… Christian Huitema
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… Christian Huitema
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… Nick Sullivan
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… Peter Gutmann
- Re: [TLS] Possible blocking of Encrypted SNI exte… Rob Sayre
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield
- Re: [TLS] Possible blocking of Encrypted SNI exte… Carrick Bartle
- Re: [TLS] Possible blocking of Encrypted SNI exte… David Fifield