Re: [TLS] Proposals to address ESNI issues

On Tue, Nov 5, 2019 at 1:58 PM Rob Sayre <sayrer@gmail.com> wrote:

> On Tue, Nov 5, 2019 at 12:35 PM Christopher Wood <caw@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.

>
>> > 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.

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.

-Ekr

> thanks,
> Rob
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>