Subject: [TLS] ESNI GREASE - answer needed?

From: Stephen Farrell <[email-masked]>
Date: Fri, 26 Jul 2019 18:31:53 +0100

Hiya,

I've started coding up the GREASE stuff from draft -04.

Aren't we missing some answering octets in EncryptedExtensions
to make it harder to tell if the CH had a real or GREASEd ESNI?

Maybe something like:

      enum {
          esni_accept(0),
          esni_retry_request(1),
          esni_grease(2),
      } ServerESNIResponseType;

      struct {
          ServerESNIResponseType response_type;
          select (response_type) {
              case esni_accept:        uint8 nonce[16];
              case esni_retry_request: ESNIKeys retry_keys<1..2^16-1>;
              case esni_grease:        uint8 grease[16];
          }
      } ServerEncryptedSNI;

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Jul 2019 20:14:32 +0100

Hiya,

(Non-stylishly responding to myself, but sometimes you
gotta...:-)

I think I understand this better now and while I still
figure a change is needed I'm not 100% sure exactly what'd
be right.

The issue I think is that draft-04 doesn't cover the case
of a server that implements ESNI but has no ESNIKeys setup,

In that case I think the right option in response to GREASE
(or what may be a real but misguided attempt at ESNI) is to
randomly return either a 16 octet value or a value that is
sized to be like a fake ESNIKeys, with e.g. 70-100 octets or
so. (That could be encoded into TLS presentation syntax in
various ways so I'll not suggest one exact way for now.)

(Before I waste time coding that up:-) Do we think the
above is correct?

Thanks,
S.

On 26/07/2019 18:31, Stephen Farrell wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Steven Valdez <[email-masked]>
Date: Mon, 29 Jul 2019 15:32:09 -0700

I don't think the server needs any special logic in the GREASE case?

If the server doesn't support ESNI, it won't respond with an ESNI extension
and the client will continue the handshake as normal.

If the server does support ESNI, it will send an esni_retry_requested with
the retry keys (since the client's record_digest is bogus) and then the
client will continue the handshake as normal.

A server that doesn't have ESNI keys configured shouldn't be responding to
ESNI and should instead just ignore the ESNI extensions (as if it didn't
know what it was).

-- 

Steven Valdez |  Chrome Networking |  [email-masked] |  210-692-4742

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Jul 2019 23:34:00 +0100

> ESNI and should instead just ignore the ESNI extensions (as if it didn't

Why?

Thanks,
S.

---

From: Steven Valdez <[email-masked]>
Date: Mon, 29 Jul 2019 15:52:48 -0700

Without GREASE, a server who doesn't have keys can't respond with any of
the existing responses (esni_accept is wrong since it can't decode the
ESNI, esni_retry_request is wrong since it can't provide keys for the
client to use on the retry). The only valid response would be a new record
type that says it doesn't support ESNI, which becomes equivalent to just
not sending the ESNI extension back in the EncryptedExtensions.

With GREASE, I don't know if it's particularly useful to fake the response
in the EncryptedExtensions, since network adversaries won't be able to see
the contents, I suppose its presence might slightly change the size of the
encrypted payload, though record padding could prevent that.

--

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 29 Jul 2019 18:53:22 -0400

It sounds like you're asking for a middle ground for servers between
"supports ESNI (and has ESNIKeys)" and "doesn't support ESNI".  Maybe you
could explain the utility of this middle ground?

>From my perspective, I'd rather encourage real implementations of ESNI than
enable fake ones.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Jul 2019 00:03:22 +0100

Hi both,

> encrypted payload, though record padding could prevent that.

Right it's the size that matters;-) I don't care if that's via
this extension or not. ISTM that yes, producing a response to
greased ESNI that doesn't stand out is an accepted requirement.
And for the case in point, I think (but don't claim to be right)
that a 50:50 distribution of ~16 payload octets or else
ESNIKeys-sized things seems right.

On 29/07/2019 23:53, Ben Schwartz wrote:> It sounds like you're asking
for a middle ground for servers between
> "supports ESNI (and has ESNIKeys)" and "doesn't support ESNI".
> Maybe you  could explain the utility of this middle ground?
>
> From my perspective, I'd rather encourage real implementations
> of ESNI than enable fake ones.

Agreed. Not that documenting a corner case is encouraging
the corner case of course:-) That seems more like being as
complete as one can.

I suspect this is more an issue about what code to write for a
server instance that boots but hasn't yet gotten the values for
ESNIKeys loaded for whatever reason. Or where disk access fails
for a while. Or where... <insert weird case here>, but the server
code still has to do something.

Cheers,
S.

---

From: David Benjamin <[email-masked]>
Date: Mon, 29 Jul 2019 19:58:27 -0400

I think the GREASE bits still need more work to avoid sticking out[*], but
you're right that there's a length leakage. But, rather than 50:50 of 16
bytes and ESNIKeys, I think it's better to pad all three cases up to an
ESNIKeys size. Whether this is done via bespoke padding within the ESNI
extension or the existing record-level padding, I don't have strong
opinions. With the server Certificate message, the draft currently just
says to pad at the record layer, so that would be consistent here too.

Additionally, the exact sizes of the TLS messages also needn't be so
obviously leaked. Servers can and should pack EncryptedExtensions,
Certificate, CertificateVerify, and Finished together into fewer records,
likely just one. This is worthwhile independent of ESNI. An encrypted
record is 22 bytes of overhead, so packing four messages into one record
saves 66 bytes. I don't know about other implementations, but BoringSSL
already does this. Of course, unpadded, an attacker that knows the expected
size of the other messages for a particular server can recover the
EncryptedExtensions length, so this isn't perfect.

[*] I filed https://github.com/tlswg/draft-ietf-tls-esni/issues/177 last
week with a sketch of an idea. Steven or I should hopefully have a more
concrete PR later.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 30 Jul 2019 01:04:53 +0100

Hiya,

> week with a sketch of an idea. Steven or I should hopefully have a more

Working from there seems like a good path. That said
I don't see that that says how an ESNI-aware but not
ESNI-configured server ought behave. And it seems a
bit complicated, although I agree a 50:50 split is as
or more arbitrary.

S.

PS: I'll note that I didn't know that PR existed as it
hadn't hit the mailing list and I rarely login to the
github web UI and that this isn't the first time I've
had that experience. I don't blame anyone but there's
clearly a bit of process stuff not quite working well
here. I think people raising non-editorial PRs should
bring those to the list.

---

From: David Benjamin <[email-masked]>
Date: Mon, 29 Jul 2019 20:11:27 -0400

> bit complicated, although I agree a 50:50 split is as

I think either of "do nothing and act like you are ESNI-unaware" or "add
some padding to EncryptedExtensions so you have room to be ESNI-configured"
is reasonable. Though, yeah, the draft should talk about this a bit. I
think the GREASE stuff turned out to have a lot more details to work out
than my original attempt anticipated. :-)

> here. I think people raising non-editorial PRs should

Apologies. I filed that during the meeting mostly so I wouldn't forget and
so Chris would have something to link to in his slides. The intent was to
write up an actual PR later which would certainly be sent to the list for
discussion.

David

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 29 Jul 2019 17:19:56 -0700

On Mon, Jul 29, 2019, at 5:11 PM, David Benjamin wrote:
> On Mon, Jul 29, 2019 at 8:04 PM Stephen Farrell 
> <[email-masked]> wrote:
> > 
> >  Hiya,
> > 
> I think either of "do nothing and act like you are ESNI-unaware" or 
> "add some padding to EncryptedExtensions so you have room to be 
> ESNI-configured" is reasonable. Though, yeah, the draft should talk 
> about this a bit. I think the GREASE stuff turned out to have a lot 
> more details to work out than my original attempt anticipated. :-)
> Apologies. I filed that during the meeting mostly so I wouldn't forget 
> and so Chris would have something to link to in his slides. The intent 
> was to write up an actual PR later which would certainly be sent to the 
> list for discussion.

+1

It is our intention to bring non-editorial PRs to the list, though sometimes we fail at doing so. Would it help if we had a script to announce GitHub draft work to the list similar to that of QUIC and HTTPBIS?

Thanks,
Chris