Re: [TLS] ESNI and padding

["Christopher Wood" <[e-mail]>]

On Thu, Jun 20, 2019, at 6:16 AM, Ben Schwartz wrote:
> 
> 
> 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.

+1 -- I don't think we ought to change the current text. 

Best,
Chris (no hat)