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

[Christian Huitema <[e-mail]>]

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