Re: [TLS] Proposals to address ESNI issues

["Christopher Wood" <[e-mail]>]

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

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]. 
> 
> 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
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>