Re: [TLS] ESNI and padding

[Ben Schwartz <[e-mail]>]

On Thu, Jun 20, 2019 at 8:04 AM Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> On 20/06/2019 12:20, Ben Schwartz wrote:
> >
> > As you are clearly aware, this approach provides essentially no privacy
> > protection in the case where a user is repeatedly connecting to a very
> long
> > domain on a server whose other domains are reasonably short.
>
> Yep. I don't believe that that's at all a common scenario,
> but if I'm wrong then sure, the approach I outlined wouldn't
> be a good plan, at least not with N=32, but maybe some other
> N would work fine. Do we know how common very long SNI names
> are? (I don't.)
>
> If we think that scenario is a real problem, that can't be
> sufficiently mitigated via picking a good N, then I guess
> always having padding_length==260 would be the only answer.
> In which case I see no upside and some downsides in having
> that field in ESNIkeys.
>
> > Rather than make a privacy-vs-efficiency tradeoff in the spec, the
> current
> > text leaves this option to the implementer.  For example, within the
> > current protocol (albeit bending the recommendations slightly), an
> > implementer could easily bucket names by length, and offer separate
> > ESNIKeys for each length bucket.  I think this is preferable; only the
> > server operator knows their own privacy and efficiency goals.  In my
> view,
> > setting N=32 for the first bucket would reproduce most of the benefits of
> > this proposal without altering the current protocol.
>
> Fair point. OTOH, if you did that, the last (or maybe even
> all but the first) bucket would likely mean an ESNIKey used
> for very few names, so you end up with the same issue you
> called out above. And it adds some more complexity to what's
> an already complicated thing. So while that could always
> be done, and with the current spec, I'd not be keen to
> recommend it myself.
>
> I just looked back at RFC8467 which recommends padding DNS
> queries to a multiple of 128 octets. I also looked at a couple
> of DNS queries on my laptop just now and there seems to be
> about 40 octets overhead over and above the qname length
> (each "." adds two octets in the encoded length vs. the
> string length it seems). So one could I guess argue for some
> commensurate amount of padding in the ESNI extension and
> whatever was used for DoT or DoH. I wonder if the data DKG
> used to generate that recommendation in 8467 might tell us
> anything here?
>

I've implemented RFC 8467 myself, and I'm grateful for the recommendation,
but I think it's rightly marked Experimental.  It's not clear how to judge
the amount of privacy protection it offers, or whether it's truly a good
balance between privacy and efficiency.

However, as a matter of overhead, your test suggests that RFC 8467 roughly
doubles the size of each query packet.  That's similar to the proportional
effect of maximum ESNI padding on a typical ClientHello.  Proportionally, I
expect RFC 8467 adds more padding to the whole DNS transaction than current
ESNI adds to the whole TLS handshake.  It might even be true in absolute
terms, on average.  In the context of a full TLS connection, the
proportional impact of ESNI is even smaller.

Again though, I think considering DNS query padding argues
> that this ought be a client-driven thing and not tied to the
> ESNIKeys.


One important difference between these cases is that DNS is essentially an
"open world", where no one knows the whole space of possibilities, whereas
a specific server is a "closed world", a finite set of domains (known only
to the server operator).  That puts the server operator in the unique
position to make correct padding decisions, and also makes the adversary's
job much easier if the padding is incorrect.

If no padding was used for DoT or DoH, the ESNI
> length may already have leaked regardless of the padded_length.
> That said, I'm not sure what, if any, padding is being done
> by DoT or DoH clients. (I use stubby and it does some padding
> sometimes but I'm not sure what.)
>

In general, I think we should assume that no SNI information is leaking
through other channels when making design choices for ESNI.  Otherwise, we
risk ESNI itself becoming the limiting factor in the future as those other
leaks are fixed.


>
> Cheers,
> S.
>
>
>
>
>