On Tue, Nov 5, 2019 at 2:43 PM Eric Rescorla <[email protected]> wrote: > >> 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." > > Ok, maybe I have misread this section. It says: "and then the key share from the second ClientHello, which is attacker-controlled". Wouldn't including more of the initial ClientHello in the AAD parameter prevent this?
thanks, Rob
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
