On Tue, Nov 5, 2019 at 1:58 PM Rob Sayre <say...@gmail.com> wrote: > On Tue, Nov 5, 2019 at 12:35 PM Christopher Wood <c...@heapingbits.net> > wrote: > >> > >> > The attacks on ESNI security above seem to stem from two problems: >> > >> > 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. >
This wouldn't change the situation in the tunnel CH, because ClientHelloInner does not depend at all on the outer part of the CH. > >> > 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). >> > > 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. 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 > thanks, > Rob > > _______________________________________________ > 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
