Subject: [TLS] Proposals to address ESNI issues

From: "Christopher Wood" <[email-masked]>
Date: Tue, 05 Nov 2019 12:28:24 -0800

Hi folks,

Since Montreal, a few people have been working on the protocol issues that currently exist in draft-ietf-tls-esni-05. To recap, here are the problems we’re aware of:

1. Server Reaction Attacks. Servers that associate SNIs with tickets may lead to dictionary attacks. An example is shown below. Adv connects to S with a guess domain guess.com and receives a ticket. Upon receiving a CH (with ESNI) from a victim client without any PSK, Adv attaches its ticket and binder to the CH, and forwards it to S. If S checks whether the ESNI in the CH matches that of the ticket and proceeds or aborts accordingly, Adv can learn whether or not its guess -- the SNI of the ticket -- matches that of the ESNI. 

2. HRR Binding Check Failure. If a server decrypts ESNI upon receiving CH and then stores it even when it sends, HRR, then an on-path attacker can intercept theHRR message, and swapping in its own KeyShare and (valid) ESNI blob. If the server fails to check that the ESNI value from the second CH matches that of the first CH. 

3. Probing Attacks. An on-path adversary changes fields in a ClientHello not bound to the ESNI extension and observes server behavior. If servers have different cryptographic configurations based on SNI, this lets an adversary learn the SNI from the server’s choice of parameters.

The attacks on ESNI security above seem to stem from two problems: 

1. The ESNI contents are not fully bound to the ClientHello contents. If this were not the case, attackers would not be able to modify ClientHello messages, either by appending ticket (binders) or swapping ciphersuites or other parameters.
2. The handshake secrets are not bound to the ESNI contents. If this were not the case, servers could not choose attacker-controlled keying material yet proceed with victim-controlled parameters (SNIs). 

We try to capture these problems in the following definitions of “forward” and “backward” binding. We say ESNI contents are forward-bound to a handshake if it is not possible to decrypt handshake messages without both the handshake shared secret and ESNI shared secret (or a value protected by the ESNI shared secret, such as the nonce). Likewise, we say ESNI contents are backward-bound to a ClientHello if it is not possible to modify a CH in any way without causing ESNI decryption.

To give ourselves confidence that these are indeed necessary for ESNI security (assuming other obvious properties such as “consistent cryptographic configuration [2]”), we worked with Karthik Barghavan to model a simplified variant of TLS 1.3 with ESNI in ProVerif. A writeup of the *preliminary* model and our findings is available at [1]. 

To satisfy these requirements, there are currently four different proposals on the table:

- ESNI encoder/decoder [3]: Add encoding/decoding layer between client and client-facing server that translates a “public” CH into a “private” CH (and back), requiring servers to choose one of these CHs to complete the handshake.
- Tunnel CH [4]: Encrypt a “private” CH under the server’s ESNI key and include it as an extension in an outer “public” CH, requiring servers to choose one of these CHs to complete the handshake.
- ESNI PSK binding with key schedule injection [5]: Bind CH contents to ESNI via a unique PSK identity (backward binding), and bind the key schedule to the ESNI contents (forward binding).
- ESNI with external PSK import and key schedule injection [6]: Same as above, except bind ESNI to the ClientHello using the external PSK importer API. 

We modelled #2 (Tunnel CH) and #3 (key schedule injection) and to give us confidence in each design. (Note that #1 and #4 are variants of #2 and #3, respectively.) (And we are actively extending these models to improve our confidence.)

Please have a close look at the above PRs and weigh in. We’d like to reach consensus on one design during (or before) Singapore. 

Thanks,
Chris (on behalf of the authors)

[1] https://github.com/chris-wood/encrypted-sni-model/blob/master/stable/esni_analysis_00.pdf
[2] https://github.com/tlswg/draft-ietf-tls-esni/issues/178
[3] https://github.com/kazuho/draft-rescorla-tls-esni/pull/1
[4] https://github.com/tlswg/draft-ietf-tls-esni/pull/196
[5] https://github.com/tlswg/draft-ietf-tls-esni/pull/197
[6] https://github.com/chris-wood/draft-ietf-tls-esni/pull/9

---

From: "Christopher Wood" <[email-masked]>
Date: Tue, 05 Nov 2019 12:34:59 -0800

On Tue, Nov 5, 2019, at 12:28 PM, Christopher Wood wrote:
> Hi folks,
> 
> Since Montreal, a few people have been working on the protocol issues 
> that currently exist in draft-ietf-tls-esni-05. To recap, here are the 
> problems we’re aware of:
> 
> 1. Server Reaction Attacks. Servers that associate SNIs with tickets 
> may lead to dictionary attacks. An example is shown below. Adv connects 
> to S with a guess domain guess.com and receives a ticket. Upon 
> receiving a CH (with ESNI) from a victim client without any PSK, Adv 
> attaches its ticket and binder to the CH, and forwards it to S. If S 
> checks whether the ESNI in the CH matches that of the ticket and 
> proceeds or aborts accordingly, Adv can learn whether or not its guess 
> -- the SNI of the ticket -- matches that of the ESNI. 
> 
> 2. HRR Binding Check Failure. If a server decrypts ESNI upon receiving 
> CH and then stores it even when it sends, HRR, then an on-path attacker 
> can intercept theHRR message, and swapping in its own KeyShare and 
> (valid) ESNI blob. If the server fails to check that the ESNI value 
> from the second CH matches that of the first CH. 
> 
> 3. Probing Attacks. An on-path adversary changes fields in a 
> ClientHello not bound to the ESNI extension and observes server 
> behavior. If servers have different cryptographic configurations based 
> on SNI, this lets an adversary learn the SNI from the server’s choice 
> of parameters.
> 
> 1. The ESNI contents are not fully bound to the ClientHello contents. 
> If this were not the case, attackers would not be able to modify 
> ClientHello messages, either by appending ticket (binders) or swapping 
> ciphersuites or other parameters.
> 2. The handshake secrets are not bound to the ESNI contents. If this 
> were not the case, servers could not choose attacker-controlled keying 
> material yet proceed with victim-controlled parameters (SNIs). 
> 
> We try to capture these problems in the following definitions of 
> “forward” and “backward” binding. We say ESNI contents are 
> forward-bound to a handshake if it is not possible to decrypt handshake 
> messages without both the handshake shared secret and ESNI shared 
> secret (or a value protected by the ESNI shared secret, such as the 
> nonce). Likewise, we say ESNI contents are backward-bound to a 
> ClientHello if it is not possible to modify a CH in any way without 
> causing ESNI decryption.
> 
> To give ourselves confidence that these are indeed necessary for ESNI 
> security (assuming other obvious properties such as “consistent 
> cryptographic configuration [2]”), we worked with Karthik Barghavan 

Correction: Karthik Bhargavan (my sincerest apologies for the typo, Karthik!)

> to model a simplified variant of TLS 1.3 with ESNI in ProVerif. A writeup 
> of the *preliminary* model and our findings is available at [1]. 
> 
> - ESNI encoder/decoder [3]: Add encoding/decoding layer between client 
> and client-facing server that translates a “public” CH into a “private” 
> CH (and back), requiring servers to choose one of these CHs to complete 
> the handshake.
> - Tunnel CH [4]: Encrypt a “private” CH under the server’s ESNI key and 
> include it as an extension in an outer “public” CH, requiring servers 
> to choose one of these CHs to complete the handshake.
> - ESNI PSK binding with key schedule injection [5]: Bind CH contents to 
> ESNI via a unique PSK identity (backward binding), and bind the key 
> schedule to the ESNI contents (forward binding).
> - ESNI with external PSK import and key schedule injection [6]: Same as 
> above, except bind ESNI to the ClientHello using the external PSK 
> importer API. 
> 
> We modelled #2 (Tunnel CH) and #3 (key schedule injection) and to give 
> us confidence in each design. (Note that #1 and #4 are variants of #2 
> and #3, respectively.) (And we are actively extending these models to 
> improve our confidence.)
> 
> Please have a close look at the above PRs and weigh in. We’d like to 
> reach consensus on one design during (or before) Singapore. 
> 
> Thanks,
> [1] 
> https://github.com/chris-wood/encrypted-sni-model/blob/master/stable/esni_analysis_00.pdf
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Rob Sayre <[email-masked]>
Date: Tue, 5 Nov 2019 13:57:45 -0800

> > 1. The ESNI contents are not fully bound to the ClientHello contents.

This seems right to me. I was surprised that the current ESNI drafts only
require the "KeyShareClientHello" as AAD input to the AEAD-Encrypt
function. Additionally, I've raised the point that even that arrangement
seems to imply that the client's key share message should appear before the
ESNI, or that the server must perform some input buffering.

Perhaps a variation on the "Tunnel CH" idea is in order: require that an
"Encrypted Client Hello" is the last extension in a ClientHello message.

> material yet proceed with victim-controlled parameters (SNIs).

I had a hard time parsing this point. Doesn't the current protocol require
echoing some encrypted content? I think the draft might need to address the
case where servers ignore the SNI and ESNI messages. Maybe that's the idea:
build this requirement into the handshake. It wasn't clear to me from the
email, though.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Nov 2019 14:14:57 -0800

> "Encrypted Client Hello" is the last extension in a ClientHello message.

This wouldn't change the situation in the tunnel CH, because
ClientHelloInner does not depend at all on the outer part of the CH.

> echoing some encrypted content?
>

Yes, but that doesn't affect the HRR splicing attack. This is laid out in S
2.2 of the document Chris forwarded.

I think the draft might need to address the case where servers ignore the
> SNI and ESNI messages.

I'm not sure what you mean by "address" this case. The purpose of the nonce
checking is to detect when ESNI was not processed.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Tue, 5 Nov 2019 14:31:12 -0800

> ClientHelloInner does not depend at all on the outer part of the CH.

I think my suggestion was that ClientHelloInner should depend on the outer
part, by requiring that it be the last extension, and using all of the
previous input in the AAD parameter.

>> I had a hard time parsing this point. Doesn't the current protocol
>> require echoing some encrypted content?
>>
>
> Yes, but that doesn't affect the HRR splicing attack. This is laid out in
> S 2.2 of the document Chris forwarded.
>

Isn't the HRR attack detailed in that section of the PDF (attachment 0 in
Chris's message) contingent on using only the "KeyShareClientHello" as
input to the AAD?

> I'm not sure what you mean by "address" this case. The purpose of the
> nonce checking is to detect when ESNI was not processed.
>

I've found that existing clients do not fail when the ESNI is not
processed. Unfortunately, I discovered this by writing a buggy client. :)

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 5 Nov 2019 14:42:42 -0800

On Tue, Nov 5, 2019 at 2:31 PM Rob Sayre <[email-masked]> wrote:

>>> This seems right to me. I was surprised that the current ESNI drafts
>>> only require the "KeyShareClientHello" as AAD input to the AEAD-Encrypt

That doesn't exactly work because the PSK extension *also* has to be last.
That's the reasoning for the injection  + PSK approach, which is
effectively this, except without duplicating the CH.

However, in the tunnelling version, you ignore the outer ClientHello when
you use the inner one, and so everything is bound together without
requiring any specific ordering.

> 2. The handshake secrets are not bound to the ESNI contents. If this were
>>>> not the case, servers could not choose attacker-controlled keying material
>>>> yet proceed with victim-controlled parameters (SNIs).
>>>>
>>>

No. In the HRR attack, the ESNI block is provided by the attacker. This is
laid out in S 2.2.

" his reveals the basic source of the problem: in order to prevent mix-and-
match attacks on the client’s key share, the ESNI encryption binds in gx.
How- ever, if the server uses the SNI from first ClientHello and then the
key share from the second ClientHello, which is attacker-controlled, then
the attacker is free to generate their own ESNI extension containing a
bogus ESNI and nonce. The server correctly verifies that these correspond
to ga but because these are all supplied by the attacker, this check
succeeds and the server encrypts the certificate to the attacker with a key
known to the attacker."

-Ekr

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Tue, 5 Nov 2019 14:54:19 -0800

On Tue, Nov 5, 2019 at 2:43 PM Eric Rescorla <[email-masked]> wrote:

> " his reveals the basic source of the problem: in order to prevent
> mix-and- match attacks on the client’s key share, the ESNI encryption binds
> in gx. How- ever, if the server uses the SNI from first ClientHello and
> then the key share from the second ClientHello, which is
> attacker-controlled, then the attacker is free to generate their own ESNI
> extension containing a bogus ESNI and nonce. The server correctly verifies
> that these correspond to ga but because these are all supplied by the
> attacker, this check succeeds and the server encrypts the certificate to
> the attacker with a key known to the attacker."
>
>
Ok, maybe I have misread this section.  It says: "and then the key share
from the second ClientHello, which is attacker-controlled". Wouldn't
including more of the initial ClientHello in the AAD parameter prevent this?

thanks,
Rob