Re: [TLS] ESNIKeys.public_name vs. cleartext SNI
Dmitry Belyavsky <beldmit@gmail.com> Sun, 28 July 2019 18:07 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 AB6BE120094
for <tls@ietfa.amsl.com>; Sun, 28 Jul 2019 11:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
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: 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 69pEUvzbXNAb for <tls@ietfa.amsl.com>;
Sun, 28 Jul 2019 11:07:39 -0700 (PDT)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com
[IPv6:2607:f8b0:4864:20::e2c])
(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 960CB12003E
for <tls@ietf.org>; Sun, 28 Jul 2019 11:07:39 -0700 (PDT)
Received: by mail-vs1-xe2c.google.com with SMTP id 2so39281414vso.8
for <tls@ietf.org>; Sun, 28 Jul 2019 11:07: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=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;
d=1e100.net; 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: <84f41a5a-b543-2fdb-8af0-b923dccd7693@cs.tcd.ie>
In-Reply-To: <84f41a5a-b543-2fdb-8af0-b923dccd7693@cs.tcd.ie>
From: Dmitry Belyavsky <beldmit@gmail.com>
Date: Sun, 28 Jul 2019 21:07:26 +0300
Message-ID: <CADqLbz+-Ht76be+WCj9YSCCKPAFLixPFRdUVyhAA7V6crhf0GQ@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: TLS Mailing List <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009aedd0058ec1a677"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wDtXZ40lXeDvOEiZlIiZEDX9p2g>
Subject: Re: [TLS] ESNIKeys.public_name vs. cleartext SNI
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, 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 <stephen.farrell@cs.tcd.ie>ie>: > > 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] ESNIKeys.public_name vs. cleartext SNI Stephen Farrell
- Re: [TLS] ESNIKeys.public_name vs. cleartext SNI Dmitry Belyavsky
- Re: [TLS] ESNIKeys.public_name vs. cleartext SNI Stephen Farrell
- Re: [TLS] ESNIKeys.public_name vs. cleartext SNI Christian Huitema
- Re: [TLS] ESNIKeys.public_name vs. cleartext SNI Stephen Farrell
- Re: [TLS] ESNIKeys.public_name vs. cleartext SNI Ben Schwartz
- Re: [TLS] ESNIKeys.public_name vs. cleartext SNI Stephen Farrell
- Re: [TLS] ESNIKeys.public_name vs. cleartext SNI Ben Schwartz
- Re: [TLS] ESNIKeys.public_name vs. cleartext SNI Stephen Farrell