Re: [TLS] ESNI robustness and GREASE PRs

[David Benjamin <[e-mail]>]

(Hit send too early)

On Tue, Dec 18, 2018 at 3:32 PM David Benjamin <[e-mail]>
wrote:

> On Tue, Dec 18, 2018 at 3:06 PM Ilari Liusvaara <[e-mail]>
> wrote:
>
>> On Tue, Dec 18, 2018 at 02:27:10PM -0600, David Benjamin wrote:
>> > On Tue, Dec 18, 2018 at 3:00 AM Ilari Liusvaara <
>> [e-mail]>
>> > wrote:
>> >
>> > > On Mon, Dec 17, 2018 at 05:17:37PM -0600, David Benjamin wrote:
>> > > > Hi folks,
>> > > >
>> > > > We[*] wrote up some proposed changes for draft-ietf-tls-esni that
>> we'd
>> > > like
>> > > > the group's thoughts on. The goal is to make ESNI more robust and
>> > > eliminate
>> > > > a bunch of deployment risks. The PRs are linked below:
>> > > >
>> > > > https://github.com/tlswg/draft-ietf-tls-esni/pull/124
>> > > > https://github.com/tlswg/draft-ietf-tls-esni/pull/125
>> > > >
>> > > > The second recommends clients to send GREASE ESNI extensions when
>> they do
>> > > > not have cached ESNIKeys available. This better meets the "Do not
>> stick
>> > > > out" goal. The server behavior in the first PR gives us this for
>> free.
>> > >
>> > > It seems to me that if server thinks it has ESNI enabled, but
>> > > the client does not get ESNI keys for it, then all handshakes fall
>> > > back to full handshake and session resumption will not work (as
>> > > the server is required to reject the resumption)?
>> > >
>> >
>> > It's possible I didn't word this correctly. If the client did not get
>> ESNI
>> > keys for the server, the client is presumably offering a non-ESNI
>> session,
>> > which has no resumption restrictions. The case we want to avoid is an
>> ESNI
>> > session being resumed at anything other than esni_accept. That's to cut
>> out
>> > the resumption case in {{verify-public-name}}. In particular, if we
>> want to
>> > tolerate partial rollouts where some servers don't support ESNI at all
>> > while others don't at all, this scenario is a concern:
>>
>> "The server MUST NOT resume any sessions offered by the client that
>> were established without ESNI.". This holds even if client sent a
>> dummy ESNI value.
>>
>
Oops, yes, that was a typo. It should have said:

The server MUST NOT resume any sessions offered by the client that were
established with ESNI.

I'll fix that. Thanks for catching that!


> > Without this case (and GREASE---see remark), we could just say servers
>> MUST
>> > NOT resume if they send esni_retry_request.
>>
>> This case the server should at least know if it has ESNI keys or not.
>>
>> > > Also, randomly generating the ESNI key handle does stick out, as
>> > > normally the ESNI key is releatively static (DNS caching!) across
>> whole
>> > > group of domains and servers.
>> > >
>> >
>> > This is true. I don't see a clear way around that one, short of taking
>> the
>> > record_digest parameter out and requiring the server do a public-key
>> > trial-decrypt for each unexpired ESNI key. (Perhaps with key mismatch
>> > tolerance, it's no longer necessary for servers to be quite so paranoid
>> > about keeping all their old keys around, but the trial-decrypt still
>> seems
>> > poor.)
>>
>> Especially with asymmetric cryptography, as even the fastest ops are
>> about 100kcyc at least (outside some very rare pieces of laptop
>> hardware).
>>
>> > I think this is still worth doing, especially as it's basically free if
>> you
>> > want to support rollbacks. (Making GREASE work and tolerating
>> ESNI-clueless
>> > servers are very strongly related. GREASE requires that servers
>> > more-or-less ignore ESNI on key mismatch.) You also need to either
>> observe
>> > multiple connections or know something about the server to do this.
>>
>> And then there might be fun with timing attacks. This is whole
>> asymmetric operation, so timing signal should be rather large.
>>
>
> Sorry, that was really confusing. By "this" I meant GREASE, not trial
> decryption schemes. :-)
>