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