Re: [TLS] Possible blocking of Encrypted SNI extension in China

Dmitry Belyavsky <beldmit@gmail.com> Sun, 09 August 2020 20:00 UTC

Return-Path: <beldmit@gmail.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 B786A3A0D3D for <tls@ietfa.amsl.com>; Sun, 9 Aug 2020 13:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.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 65GQKqswixq5 for <tls@ietfa.amsl.com>; Sun, 9 Aug 2020 13:00:40 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47EA3A0D3C for <tls@ietf.org>; Sun, 9 Aug 2020 13:00:39 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id di22so4905009edb.12 for <tls@ietf.org>; Sun, 09 Aug 2020 13:00:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DyxNcgA7dihouZddMvW0k0Wz6nmq2KkP8MGTq/KGg04=; b=SAXyqpgboSo2KH+iJ4Yj+3S7T2guUveRsuQzvTCoGntHRYBGGUZoH+A4M2tDM2bxsx 4C2a0kY9gWrkxxsJgxOadNgzSKMiHD63nl7ndz5tgA/NLyRaSbD8oF8ghA7ENri5kb4j 9NLjtzhSbfvZwE+eAS1uLitbTEU011ELW2alP6srENa0/3666pjfIcv2B0ocnSW72Qdo jPQrRj9SD7Hx/lY9G13xNHBkq3Z09DLwkiBS649lInWWAcs59uS/wQCpxeWL28xz+Mpa eWyakGSZYkNWGdKAq/WA+qqEgLIlo17JOFDtiTwZ/zve+SIMBvfNHZOp4NU3lPypQVjE SpLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DyxNcgA7dihouZddMvW0k0Wz6nmq2KkP8MGTq/KGg04=; b=evxcx4GrYfItetTCE+b16Cbdu/FDrOOA6Ylb3Rxc3YZMnFlzbKy9Hx9BSJD/L2SCfV wc319a7m9EeMhVaehgJmY5uuAx3FA3GGUF+IoFsIlPIR/rKuZX53u5VoUV60sakURuh4 N6dPgLbsg7DVjZG3ecbHPpUJs63voFVBxWLDTUY19etJuMl97eRbg7oyeety708v3xiX DmETzSH3xSI2kW0qZ3Ngsnxntx9xNfgrzAHaAqa0D1VZyN7oEkU9pG350LVkXl2M6zGj wFyAcUkBkYQgS4nT38Gzjchro7aXSs2IqDwyF/vyNkPjqYx74LstI6zP4LxmTFTvQgtD Ashw==
X-Gm-Message-State: AOAM5339k/Vz7s9vnTlLPnRO/el3lppSKTQZacNAhIugFh62K/DyaxGJ rdPeQUYWYnto9AshHvrh28erI3iUhyFcVZsVZReVJ77u0RM=
X-Google-Smtp-Source: ABdhPJzO+ZivNu70wuAa6LvnVmHv9sIc+HGLOrrZJTQ0GSSa0n9RCii+W2AcOsGy1u5nVfp94hiqMhJwXbQWltlPVdk=
X-Received: by 2002:a05:6402:68b:: with SMTP id f11mr18798326edy.353.1597003238177; Sun, 09 Aug 2020 13:00:38 -0700 (PDT)
MIME-Version: 1.0
References: <20200809153526.vf5zlongieoswb22@bamsoftware.com> <3EF34460-F688-453E-867E-9699480BD199@ll.mit.edu>
In-Reply-To: <3EF34460-F688-453E-867E-9699480BD199@ll.mit.edu>
From: Dmitry Belyavsky <beldmit@gmail.com>
Date: Sun, 9 Aug 2020 23:00:27 +0300
Message-ID: <CADqLbzKQcONeEjJ5w-8pgU38ae5B+QYuoyzftEQXWQ++3Gk0EQ@mail.gmail.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Cc: David Fifield <david@bamsoftware.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b77f2705ac774acc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/p1gi-L8QQjYN7Wdn-9hDs4saqNw>
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 20:00:42 -0000

I just want to remind you about my FakeSNI draft

https://tools.ietf.org/html/draft-belyavskiy-fakesni-02

The idea behind it was cheating the solutions less sophisticated than GFW.
Yes, in real life it will require deep cooperation between DNS and hosting
and yes, the resource still can be blocked by IP (with all collateral
damage).

On Sun, Aug 9, 2020 at 8:15 PM Blumenthal, Uri - 0553 - MITLL <
uri@ll.mit.edu> wrote:

> I’m pretty sure your reasoning is wrong. In the ideal world, if
> *everybody* enabled ESNI - then *maybe* the GFW would relent.
>
> The way things are - is not smart pretending reality is not what it is.
>
> Using your terminology - better blend with the crowd, because you aren’t
> likely to live long enough to see the crowd change to match you.
>
> There are a lot of technical details why the whole crowd won’t change
> regardless of your wishes - e.g., who controls TLS implementations in
> various devices - but I won’t go there.
>
> Regards,
> Uri
>
> > On Aug 9, 2020, at 11:36, David Fifield <david@bamsoftware.com> wrote:
> >
> > 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 mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
SY, Dmitry Belyavsky