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