Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt

Christian Huitema <> Tue, 02 June 2020 23:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 878F53A10D6 for <>; Tue, 2 Jun 2020 16:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QfsLiTMFpGqI for <>; Tue, 2 Jun 2020 16:01:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A200F3A10D0 for <>; Tue, 2 Jun 2020 16:01:43 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1jgFue-0005nU-JC for; Wed, 03 Jun 2020 01:01:42 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 49c6Lm60G6z6PY0 for <>; Tue, 2 Jun 2020 15:35:28 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1jgFVI-0001Y3-Ni for; Tue, 02 Jun 2020 15:35:28 -0700
Received: (qmail 6092 invoked from network); 2 Jun 2020 22:35:28 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 2 Jun 2020 22:35:28 -0000
Content-Type: multipart/alternative; boundary="Apple-Mail-C06B0663-550D-4625-B134-BC743A22273E"
Content-Transfer-Encoding: 7bit
From: Christian Huitema <>
Mime-Version: 1.0 (1.0)
Date: Tue, 02 Jun 2020 15:35:27 -0700
Message-Id: <>
References: <>
Cc: "Salz, Rich" <>, Stephen Farrell <>, Christopher Wood <>, "" <>
In-Reply-To: <>
To: Ben Schwartz <>
X-Mailer: iPhone Mail (17E262)
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T32zu7lnXf5JHTxKFqDV/OpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDnUBp1CHDvSSSf3ax1RWBzOfH zJ6mVE7ewsipSVIfs4YHrj5Ke9hrHZgZIkL6h0ZIgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+ejwQhTyQ8EpXEbK2N9rfagUz0sPgnpAk2KA2vJwMd1uY6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAmxx/Wk8McinP JEkgAVrOMpbpEBI3TsF8NtmMf8bfn4eBGr8dhfYPz+NSUYLHTfE0nFgJkowUXTKFU/ElT0PlbdL0 lSfuxANzRU5MAZzTOSGBYfVOjkou/1Xrs00iK3J96vKY2AXNZGS5G93aGyH8MqMNONNOB63tZ91H 4Bn0Oix6KWDRtf6HJAeNdm4/n62X9JxMPnetLBJMh51NiRRoHIBfD5ye+ePcSbVNKKdHpO0GmiK7 x42VjdzChZMe6O/DiWiiIzuXMTE3l4bIsk+O50sSb7DLwUyExrL04iJcS+/F08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho=
Archived-At: <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt
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: Tue, 02 Jun 2020 23:01:46 -0000

> On Jun 2, 2020, at 2:26 PM, Ben Schwartz <> wrote:
>> On Tue, Jun 2, 2020 at 4:50 PM Christian Huitema <> wrote:
>> On 6/2/2020 11:44 AM, Salz, Rich wrote:
>> > Trial description scares me.  Perhaps that's not a rationale fear -- one of the points of CDN support is a large anonymity set -- but I worry about the DoS possibilities. Especially if QUIC picks this up (now trivial to fake "client IP") and if some large mobile manufacturers move to use this as the default as I've heard they are considering.
>> I am looking at a very specific use case: mobile servers.
> Presumably, connecting to a mobile server requires a rendezvous (a.k.a. "signalling") channel, in order to learn its current IP address.
>> Suppose that
>> you use TLS to connect from a mobile client to a mobile server using an
>> untrusted network, such as a Wi-Fi network in an airport. Neither the
>> client not the server want to reveal their identity when using the
>> network. When using TLS, they will use ECH to hide finger-printable data
>> such as SNI, ALPN, or QUIC initial parameters. But the record digest in
>> the ECH blob is also an unique identifier of the server.
> For your use case, if the server's IP address is dynamic, and discovered through a rendezvous channel, can its ECH blob also be dynamic, and discovered through the same channel?

We actually spent a fair bit of time studying this discovery problem in DNSSD. Turns out that all practical solutions involve some form of trial decryption, such as sending "are you there" question encrypted with the public key of the server -- or alternately "I am here" encrypted with the public key of the client. In both cases the public keys have to be maintained private so only authorized clients or server know them. You can poke at various corners of the problem, and you always end up with one of these two variants.

One very simple design in that pattern is to just broadcast the ECH in an initial UDP message, and have the server only responds if it can decipher the ECH. That would work with Quic or DTLS.

Of course you could always add a level of indirection, but you will still end up with a trial decryption pattern. I am not sure that the additional complexity is worth it.

-- Christian Huitema