On Tue, Nov 5, 2019 at 2:31 PM Rob Sayre <say...@gmail.com> wrote: > > > 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. >
That doesn't exactly work because the PSK extension *also* has to be last. That's the reasoning for the injection + PSK approach, which is effectively this, except without duplicating the CH. However, in the tunnelling version, you ignore the outer ClientHello when you use the inner one, and so everything is bound together without requiring any specific ordering. > 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? > No. In the HRR attack, the ESNI block is provided by the attacker. This is laid out in S 2.2. " his reveals the basic source of the problem: in order to prevent mix-and- match attacks on the client’s key share, the ESNI encryption binds in gx. How- ever, if the server uses the SNI from first ClientHello and then the key share from the second ClientHello, which is attacker-controlled, then the attacker is free to generate their own ESNI extension containing a bogus ESNI and nonce. The server correctly verifies that these correspond to ga but because these are all supplied by the attacker, this check succeeds and the server encrypts the certificate to the attacker with a key known to the attacker." -Ekr > >> 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. :) > -Ekr > thanks, > Rob >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
