Re: [TLS] Proposals to address ESNI issues

[Rob Sayre <[e-mail]>]

On Tue, Nov 5, 2019 at 2:43 PM Eric Rescorla <[e-mail]> 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