Re: [TLS] ESNIKeys.public_name vs. cleartext SNI

Dmitry Belyavsky <> Sun, 28 July 2019 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB6BE120094 for <>; Sun, 28 Jul 2019 11:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 69pEUvzbXNAb for <>; Sun, 28 Jul 2019 11:07:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 960CB12003E for <>; Sun, 28 Jul 2019 11:07:39 -0700 (PDT)
Received: by with SMTP id 2so39281414vso.8 for <>; Sun, 28 Jul 2019 11:07:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GZLJTyuXINMPcRSwSsF3HfDa0PyENbWVhcWwLaB+Ds8=; b=UFtBoUl4eabuChTVrJ1UijGegSQ8Dnk8lgxlsreTgIrsixz8hHc+DpQDG1r/PFnAp4 LUyz+gHBBuKugAqJjwJ5T4Dwhr6l55RXzlHZsOvE1mcGTFtvR9FBQLrxaKGGm6xlLUnj Tl7GvYq42aT5thRHxs/VmUfK0C5mOIWBkZuIKq48qG0HpsaJHqXnDXFW2zqI6Fv4WK/P /9+dA9ZIuR1ddMESSm6/tIeNoiMYEY1kM6Fgr4/de6u+tqFwPhtI0AywG8PJg4dxAyK2 Csc0gAtnuPgiJpPXx/UeBwt4h7EtfVtD4hg9R803tGWq6QRac9nPNR0Daze8bD27XmFy TqjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GZLJTyuXINMPcRSwSsF3HfDa0PyENbWVhcWwLaB+Ds8=; b=Lq84xBzQ4cQJZK9rUNtLL7ui5aq0vm2H4KDJX5KSRcJ1467LwSMz68DvX5OW4nx+4c OE441K47thK5iTAqaO3TkMIE1sJ5f9ejWR7m2q/fIa2osxwO+j2GY1YMkhQ7pK3685bT 2tnatbZAiiqa/JJEsKoeicaC5TJtSYEhkyyCc26WWEC0fnvd/zwT6Hy2+CcQGSK35YE2 Rm8IS3VqDNefKkDueFgR20htD0+Onu2RY6gJ0+Lzr6gZ/7uRR2plPzHXwkKECBPwzWZA I1/NsGCZZM2MXadZOfqtBKp5pb2yZE6v76gNSD2GGClvxJ5kDxOMpIoBSdtAxKLGGrdF lx1Q==
X-Gm-Message-State: APjAAAVz39qJ+eVR/5Y2xx46H3vAc+RY2gYc3SzNDxzwp/4CCmr/z2v2 ta0zl8YiNKMOeDlYiAGYENLHrxinaDKGC+bQRua2Wn30
X-Google-Smtp-Source: APXvYqyhUka7wcd6w4ZNOv+jvM/mIqYuF6y709BEOdLObgAiU5yAZFeuUY7MO6vX2bkcBrIeh9mpv2qVrypLvkhcyb4=
X-Received: by 2002:a67:f618:: with SMTP id k24mr65965866vso.66.1564337258555; Sun, 28 Jul 2019 11:07:38 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dmitry Belyavsky <>
Date: Sun, 28 Jul 2019 21:07:26 +0300
Message-ID: <>
To: Stephen Farrell <>
Cc: TLS Mailing List <>
Content-Type: multipart/alternative; boundary="0000000000009aedd0058ec1a677"
Archived-At: <>
Subject: Re: [TLS] ESNIKeys.public_name vs. cleartext SNI
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 28 Jul 2019 18:07:42 -0000

Dear Stephen,

I published a draft describing "Fake SNI" designed for the same purpose. It
allows (at least in theory) to cheat those who blocks all the handshakes
containing ESNI.

вс, 28 июля 2019 г., 15:25 Stephen Farrell <>:

> Hiya,
> ESNI drafts -03 and -04 envisage that the ESNIKeys.public_name
> and the TLS h/s cleartext SNI are the same. I'd expect that
> they mostly will be.
> But they don't have to be. A client could provide a way to
> use a client-chosen cleartext SNI when using ESNI to encrypt
> the real SNI.
> For example, my openssl build allows this for s_client. I've
> a colleague who's got a first build of curl using that that
> also allows such a local over-ride. I think other command-line
> clients might be likely to also support that kind of thing, if
> for no other reason than the existence of the draft-02 version
> that's deployed and has no public_name. But I guess being able
> to do a local over-ride may also be generally useful, while
> not being so useful for web browsers. For example, if a given
> public_name value is being censored, clients might at that
> point want to use something else.
> On the server side, my code also make no checks that the
> cleartext SNI used was the same as the public_name. And I
> don't think that causes any problems, so maybe ought be
> allowed too.
> I don't think allowing this (if the WG decide to) requires
> any major change to the spec, but there are a couple of
> language changes needed in section 5.1.3 and I guess we
> should add a sentence to the effect that using the public_name
> value from ESNIKeys in the cleartext SNI is recommended
> if you've no other value but is not required.
> Cheers,
> S.
> _______________________________________________
> TLS mailing list