[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] ESNI and padding
From: "Christopher Wood" <caw () heapingbits ! net>
Date: 2019-06-25 20:49:05
Message-ID: 9a94a3ec-062f-480c-b98b-a8d2f704ae50 () www ! fastmail ! com
[Download RAW message or body]
On Thu, Jun 20, 2019, at 6:16 AM, Ben Schwartz wrote:
>
>
> On Thu, Jun 20, 2019 at 8:04 AM Stephen Farrell
> <stephen.farrell@cs.tcd.ie> 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)
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic