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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E6F23A1111 for <>; Tue, 2 Jun 2020 16:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 WGzBtKUt0vNM for <>; Tue, 2 Jun 2020 16:38:07 -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 8F7F63A1110 for <>; Tue, 2 Jun 2020 16:38:07 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1jgGTs-000Oo5-8A for; Wed, 03 Jun 2020 01:38:05 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 49c73N0NNZzL7J for <>; Tue, 2 Jun 2020 16:07:12 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1jgFzz-0002km-Uf for; Tue, 02 Jun 2020 16:07:11 -0700
Received: (qmail 23772 invoked from network); 2 Jun 2020 23:07:11 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 2 Jun 2020 23:07:11 -0000
From: Christian Huitema <>
To: Ben Schwartz <>
Cc: "" <>
References: <> <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <>
Date: Tue, 02 Jun 2020 16:07:10 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------E17D2E7A547FFED7ACC711E5"
Content-Language: en-US
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 zJ6mVE7ewsipSVIfs4YeJJcL7JhnvoXQb9Ax6VdzgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+ef7heanb/rBmrs7JMJfZdiPM2DmctUkuqITdPZ8a3LuY6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm1iez9GB/vVI PBTzV+UYoQ41LX6w8nTNDx15MayNoznTIz56flK3z1Qgu4uaza5o/3NG68GHGqBe+Ps2e3wNj5Pv 5pWb82qAoDl3ILGSF0vmDvI0DEihOd7XzCAIcFZdY11677oPXF7r5zsW33ZNliqbq1iQQhopQxqA dW22RV24Gz0gAbxdMJWOBl4MellXNzzAXPU1UvCyITFs2AML0PpRtTQ6Yt0CQ0Vtxw3LoF8VHHAS JNUmoOHSoqgqxfHmWRWcrRhLeB34s3hUb32GO+3aZrQ0ZYZgxsMxEZFhU2WM08QV3No+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:38:09 -0000

On 6/2/2020 3:35 PM, Christian Huitema wrote:
>> 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.

Sorry, not enough coffee. You can also send an "I am here" message
encrypted with the private key of the server, provided only authorized
clients know the public key. And "I am here, are you there", encrypted
with the private key of the client, assuming only authorized servers
know the public key of the client. But the point remain, you need trial
decryption in all these cases if you don't want to expose the identities.

> 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.

.. With correction

-- Christian Huitema