Re: [TLS] ESNI GREASE - answer needed?

[Stephen Farrell <[e-mail]>]

Hi both,

On 29/07/2019 23:52, Steven Valdez wrote:
> 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.

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.


> 
> 
> On Mon, Jul 29, 2019 at 3:34 PM Stephen Farrell <[e-mail]>
> wrote:
> 
>>
>>
>> On 29/07/2019 23:32, Steven Valdez wrote:
>>> 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).
>>
>> Why?
>>
>> Thanks,
>> S.
>>
> 
>