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

[Christian Huitema <[e-mail]>]

On 6/2/2020 3:35 PM, Christian Huitema wrote:
>
>> On Jun 2, 2020, at 2:26 PM, Ben Schwartz <[e-mail]> wrote:
>>
>> 
>>
>>
>> On Tue, Jun 2, 2020 at 4:50 PM Christian Huitema <[e-mail]
>> <mailto:[e-mail]>> 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