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