On Tue, Nov 5, 2019 at 2:15 PM Eric Rescorla <e...@rtfm.com> wrote: > > > 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. >
I think my suggestion was that ClientHelloInner should depend on the outer part, by requiring that it be the last extension, and using all of the previous input in the AAD parameter. > > > >> >>> > 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. > Isn't the HRR attack detailed in that section of the PDF (attachment 0 in Chris's message) contingent on using only the "KeyShareClientHello" as input to the AAD? > 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. > I've found that existing clients do not fail when the ESNI is not processed. Unfortunately, I discovered this by writing a buggy client. :) thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
