Re: [TLS] draft-ietf-tls-esni feedback

[Stephen Farrell <[e-mail]>]

Hiya,

On 23/10/2019 22:45, Christopher Wood wrote:
> On Wed, Oct 23, 2019, at 2:12 PM, Stephen Farrell wrote:
>> 
>> 
>> On 23/10/2019 17:13, Ben Schwartz wrote:
>>> On the topic of radical suggestions, here's another one: 
>>> https://github.com/tlswg/draft-ietf-tls-esni/pull/186
>> 
>> How about a variant like this (which is maybe close to your most
>> recent email, not quite sure):
>> 
>> Names < N octets: pad those to N.
>> 
>> Names >= N octets: hash those and pad to N.
>> 
>> With N ~=64 I think that'd be ok, assuming we do some checking that
>> N covers a sufficient percentage of names in real use.
> 
> For this and other proposals, it seems there's different assumptions
> being made. I'd prefer to not make any change absent further analysis
> with clear guidance pointing towards a safe policy. Absent that, the
> safest approach (260B) seems prudent.

Fixed at 260 octets is better that what we have and safest, yes.
I think we could do better though, but agree that proposals for
that need analysis.

>> I think the WG could easily make the case that if some web site
>> really does need/want to hide in the crowd, they just better not
>> try do that with a gigantic DNS name.
> 
> Why would such a site use ESNI at all?

My hope is browsers and sites might all just use ESNI eventually.
But I think we are ok to consider that over-sized names may face
some implementation obstacles. I suspect, but don't know, that
hash based approaches are liable to break server-internal APIs
in various ways. But that might be ok, if the numbers are small
enough.

Cheers,
S.

PS: Despite raising the above variant, I still think "behave
the same as DNS query padding as far as possible" is still the
right approach to try next. Given DNS query padding works, that
is I think, as safe as a fixed use of 260 octets.

> 
> Best, Chris
> 
> _______________________________________________ TLS mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/tls
>