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

Christian Huitema <huitema@huitema.net> Mon, 29 July 2019 00:43 UTC

Return-Path: <huitema@huitema.net>
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 9A3E912004F for <tls@ietfa.amsl.com>; Sun, 28 Jul 2019 17:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 mV74kd2szjtS for <tls@ietfa.amsl.com>; Sun, 28 Jul 2019 17:43:57 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 D90B212003E for <tls@ietf.org>; Sun, 28 Jul 2019 17:43:56 -0700 (PDT)
Received: from xse156.mail2web.com ([66.113.196.156] helo=xse.mail2web.com) by mx62.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1hrtla-0003Vb-L1 for tls@ietf.org; Mon, 29 Jul 2019 02:43:55 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 45xgcZ2Ch5z32Xk for <tls@ietf.org>; Sun, 28 Jul 2019 17:32:14 -0700 (PDT)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1hrtaI-0006VU-6S for tls@ietf.org; Sun, 28 Jul 2019 17:32:14 -0700
Received: (qmail 6268 invoked from network); 29 Jul 2019 00:32:13 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.38.95]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tls@ietf.org>; 29 Jul 2019 00:32:13 -0000
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "tls@ietf.org" <tls@ietf.org>
References: <84f41a5a-b543-2fdb-8af0-b923dccd7693@cs.tcd.ie>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <05501e58-6d97-c2b6-6e76-bc4c3b2f4579@huitema.net>
Date: Sun, 28 Jul 2019 17:32:00 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <84f41a5a-b543-2fdb-8af0-b923dccd7693@cs.tcd.ie>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="SEsL8MPCqC1HRgvTrmH6isBS38Qh6EuA2"
X-Originating-IP: 66.113.196.156
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.156/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.156/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0STiPCilqAig5bem4hJMKBmpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4biXaF3EpvjDGrTTQzQdj36gyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+e8hb1lxHddBtWcfnl7xl+wmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdGd9U9Oojh2QY0MMPWjRsTVhMmX9VvKuj6psZloQqgYBwH0r+197ykuYmDR9wbL2 DBEuqNMl4E+tMKMsv/A3u4xFRxF9LSHNsZFl22lrRRn/H0knlMgOQTVp+x1fo2EPmz5tsQu9R3vp aAMkTA7gTKoJngF7rJQgeWTjF5V/EGvRxRajR0YsmQLbkjh+XPtp2xO8u0ag4+i9kLOW9cRnakej RNBr7jDwr0sAl4gUSJEki/jsU5ildGCaI63SvQizCpq7xqDoiTjjGpNS1XGXbXKoKVG8QfD0FbAY dB+AJQ4DAztqzrCt4TZ/wLtujY/tpcO3rEhC6hy6qW9LXGyYHMwU/75QBEhYYdlOvzV2F8hHPAlb DjazCbhs7qBpykynMha5/rijjcguRYfyvX/qs6Br1HXtUZgvqUTL5xpxMJrF83g9ueTJOU6a76yp yxjdeg8YhWenlMfuvb1mNY5/IPiuedK/Z3MvnAyDmuOaA5CGZRWsGw8ac2InzcAP/gmxwNpms+rB 6wJM+NNhN3aT35NSU/fjw6KbqLw80r1gDO3m6U0LjBzYuQztdAThgtWSU3qCINKqlAdh+ePAcEwD s/8=
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Ysew8At98LbVIwpuooInhrvRBkQ>
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: Mon, 29 Jul 2019 00:43:59 -0000

On 7/28/2019 5:25 AM, Stephen Farrell wrote:
> 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.

I see the intent, but I am not sure it is practical. A lot of the HTTP
connection establishment is automated. Given a server name, the client
will do a lookup for the ESNI record or a cached value. If there is one,
the simple solution is to put the public name in the SNI extension and
the actual name in the ESNI extension. If the public name is censored,
the solution is probably to look for a different ESNI record for the
server, one that would mention a different public name.

By the way, I think that the current ESNI record is maybe a little too
complicated. The ESNI key is really a property of the public server, yet
the ESNI record is defined as a property of the hidden server. If the
public server rolls a new key, all the ESNI records of all the hidden
servers that mentioned the old key need to be updated. I think it would
be simpler to have the ESNI record as a property of the public server,
and to just have a pointer to the public server in the context of the
hidden server. May an SRV record. The chain would be something like:

1) Look up whether the SRV record for _esni._tcp.hidden.example.com

2) If there are such records, select the appropriate public server, say
public.example.net

3) Look up ESNI, A, AAAA for public.example.net

In that architecture, there is no need to encode the public server name
in the ESNI record. I think there will be several advantages. The ESNI
record's TTL can be set to the lifetime of the key. The SRV record's TTL
can be set to the expected lifetime of the relation between 'hidden" and
"public". If the SRV lifetime is long enough, the value can be
efficiently cached by the client. If multiple clients share the same
hidden server, the ESNI record is fetched only once, and can be cached.
At connection time, the client would only need to query the A/AAAA
records of the public server, i.e. exactly the same DNS transaction as
an access to the public server.

-- Christian Huitema