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

From: [email-masked]
Date: Mon, 01 Jun 2020 12:41:56 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : TLS Encrypted Client Hello
        Authors         : Eric Rescorla
                          Kazuho Oku
                          Nick Sullivan
                          Christopher A. Wood
	Filename        : draft-ietf-tls-esni-07.txt
	Pages           : 31
	Date            : 2020-06-01

Abstract:
   This document describes a mechanism in Transport Layer Security (TLS)
   for encrypting a ClientHello message under a server public key.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-esni-07
https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-esni-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Christian Huitema <[email-masked]>
Date: Mon, 1 Jun 2020 22:06:27 -0700

This draft looks really good. I just have two questions of clarification.

I am not sure that I understand the point made in appendix B, Total
Client Hello Encryption. The text in that appendix explains that "The
design described here only provides encryption for the SNI, but not for
other extensions, such as ALPN." This seems to contradict the design
description in the introduction, "The design in this document introduces
a new extension, called Encrypted Client Hello (ECH), which allows
clients to encrypt the entirety of their ClientHello to a supporting
server." Am I correct to assume that the text in appendix B is a
leftover from the previous version of the draft?

I am also not sure on how we could implement the "Optional Record
Digests and Trial Decryption" methods described in section 10.3. The
syntax description in section 5 specifies the record digest as "opaque
record_digest<0..2^16-1>", and defines that field as containing "A
cryptographic hash of the ECHConfig structure from which the ECH key was
obtained". Would it be correct to implement the "optional record digest"
method by just encoding a zero length field?

-- Christian Huitema

On 6/1/2020 12:41 PM, [email-masked] wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 02 Jun 2020 05:44:08 -0700

On Mon, Jun 1, 2020, at 10:06 PM, Christian Huitema wrote:
> description in the introduction, "The design in this document 
> introduces a new extension, called Encrypted Client Hello (ECH), which 
> allows clients to encrypt the entirety of their ClientHello to a 
> supporting server." Am I correct to assume that the text in appendix B 
> is a leftover from the previous version of the draft?

Yep! I'd opt to remove this text entirely, but if others want to keep it I suppose we can update the text accordingly. 

> cryptographic hash of the ECHConfig structure from which the ECH key 
> was obtained". Would it be correct to implement the "optional record 
> digest" method by just encoding a zero length field?

Indeed, that was the intent. Would you prefer a different way?

Best,
Chris

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Jun 2020 10:28:27 -0700

> Yep! I'd opt to remove this text entirely, but if others want to keep it I suppose we can update the text accordingly. 
That's probably the simple option, yes.
> Indeed, that was the intent. Would you prefer a different way?

Length 0 is a fine way to mark the absence of an optional component. But
I would like a short mention of that either in section 5 or in section
10.3. For example:

10.3.  Optional Record Digests and Trial Decryption

   Optional record digests may be useful in scenarios where clients and
   client-facing servers do not want to reveal information about the
   client-facing server in the "encrypted_client_hello" extension.  In
   such settings, 

>>                clients prevent server identification by sending
>> an empty record_digest field in the ClientEncryptedCH, and 

                  servers must perform trial decrypt upon receipt of an
   empty record digest, which may exacerbate DoS attacks.  Specifically,
   an adversary may send malicious ClientHello messages, i.e., those
   which will not decrypt with any known ECH key, in order to force
   wasteful decryption.  Servers that support this feature should, for
   example, implement some form of rate limiting mechanism to limit the
   damage caused by such attacks.

Fairly minimal change, but it would clarify the intent and avoid interop
problems.

-- Christian Huitema

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 02 Jun 2020 11:18:35 -0700

On Tue, Jun 2, 2020, at 10:28 AM, Christian Huitema wrote:
> > Yep! I'd opt to remove this text entirely, but if others want to keep it I suppose we can update the text accordingly.  That's probably the simple option, yes.
> Length 0 is a fine way to mark the absence of an optional component. 
> But I would like a short mention of that either in section 5 or in 
> section 10.3. For example:
> 
> 
> 
> Fairly minimal change, but it would clarify the intent and avoid 
> interop problems.

Would you mind creating a PR for this? :-)

Thanks,
Chris

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 2 Jun 2020 19:30:49 +0100

Hiya,

Sorry if I'm missing a bit of context...

> an empty record_digest field in the ClientEncryptedCH, and 

That seems to me to be an unnecessary breach
of the do-not-stick-out requirement. In my code
it was quite easy to attempt trial decryption
(if so configured). I don't think there's an
expectation of a use-case where the number of
keys in use would be so high as to cause a problem.
So I'd prefer the client in that case to just
send random data of the usual length.

That said, ECH is sticking out a lot already
so this is not a huge deal;-)

Cheers,
S.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 Jun 2020 18:44:56 +0000

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.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Jun 2020 13:00:12 -0700

> so this is not a huge deal;-)

I see your point, Stephen. Length=0 is a clear signal to the server, so
server processing is just a bit easier than sticking a random number
that looks like a SHA256 hash, or whatever the cipher-suite mandates.
With length=0 third parties can casually observe that "this server wants
to remain private"; with random numbers they can only observe that the
record digest does not match any of the digests that they are tracking.
Random numbers are thus a little bit better for privacy, at the cost of
a little bit more work for the server.

As I said, my first goal is to avoid silly interop issues and have a
recommended behavior for servers that desire privacy. Chris is nudging
me to create a PR;  If the consensus is for random numbers, I will put
that in the PR.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Jun 2020 13:13:22 -0700

> 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 t…

I am looking at a very specific use case: mobile servers. 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. Sending that in
the clear will disclose the identity of the server if the ECHConfigis
public. Even if server and authorized clients keep the structure
private, the unique record digest still allows for tracking the server's
movements. In practice, server privacy pretty much requires trial
decryption -- any hint at server identity or key identity can be used to
track the server.

Of course, this is a specialized use case. This kind of behavior is not
required at all if the client-facing server is public, such as in the
CDN case. Servers will have to explicitly allow the feature, and yes
this is a trade-off between privacy and exposure to DDOS. The point of
section 10.3 is precisely to outline that trade-off.

-- Christian Huitema

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 2 Jun 2020 17:26:02 -0400

On Tue, Jun 2, 2020 at 4:50 PM Christian Huitema <[email-masked]>
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
> 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?

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Jun 2020 15:35:27 -0700

> On Jun 2, 2020, at 2:26 PM, Ben Schwartz <[email-masked]> wrote:
> 
> 
> 
> 
>> On Tue, Jun 2, 2020 at 4:50 PM Christian Huitema <[email-masked]> wrote:
> Presumably, connecting to a mobile server requires a rendezvous (a.k.a. "signalling") channel, in order to learn its current IP address.
>  
>> Suppose that
> 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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 2 Jun 2020 16:07:10 -0700

On 6/2/2020 3:35 PM, Christian Huitema wrote:
>> On Tue, Jun 2, 2020 at 4:50 PM Christian Huitema <[email-masked]
>> <mailto:[email-masked]>> 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.
>>
>> Presumably, connecting to a mobile server requires a rendezvous
>> (a.k.a. "signalling") channel, in order to learn its current IP address.
>>  
>>
>>     Suppose that
>> 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