Re: [TLS] ESNI and padding

[Eric Rescorla <[e-mail]>]

On Wed, Jun 19, 2019 at 3:34 PM Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> TL;DR: I think we ought remove the ESNIKeys.padded_length field,
> define a purely algorithmic padding scheme with no configuration
> needed and RECOMMEND that people using ESNI don't use names that
> are exceptionally long.
>
> In the web, ESNI is hides the web site to which a browser is
> connecting but there are a few ways in which the lengths of
> handshake fields could give the game away. So the current
> draft provides mechanisms to avoid those issues in the
> handshake. But I think we can do better with less.
>
> (As a side-note - the ESNI spec is not trying, and shouldn't try,
> to define how to pad TLS application traffic. While that is something
> that will need to be figured out, it's out of scope for ESNI, which
> rightly only deals with the handshake IMO.)
>
> My main problem with the current approach is that a server might not
> (easily) know the longest name or certificate that they will serve
> for the duration for which one ESNIKeys value is current.  I've come
> across openssl related code and mails that indicate that server code
> accesses the server cert and private key via a DB lookup.  That DB
> might not be readily searchable for whomever generates the ESNIKeys.
> The current draft calls for fixing the padded_length in the ESNIKeys
> structure published in the DNS to cover the longest needed.  It
> could easily be problematic to ensure those don't get out of whack,
> leading to avoidable error cases. The current approach also links
> the cadence with which one updates the DNS with how often new TLS
> server certificates appear, which seems like an undesirable and
> unnecessary linkage. And of course, while the length of the
> server name is under local control, the length of certificates
> is not.
>
> Separately, I think the current approach will lead to deployments
> over-estimating the padding needed "just in case", e.g. CF's
> deployment calls for padding to 260 octets (and I've copied
> that in mine so far:-) I would assume CF picked that number
> for that not-great "just in case" reason but don't know. In any
> case, 260 seems wasteful to me and if it ended up widespread
> could cause an issue later if the ClientHello gets bigger for
> other reasons, and/or if someone started to depend on it for
> some weird reason.
>
> What I'd suggest instead:
>
> - delete the padded_length field from ESNIKeys, so nobody needs
>   to configure anything for padding
> - clients MUST pad to a multiple of N octets where N is in the
>   spec (I'd suggest N=32, but any number that's longer than
>   nearly all real TLS server names would be good)
> - we RECOMMEND clients randomly add an additional N octets of
>   padding with probability X%, perhaps with X=10 (btw - am I
>   right in thinking that if X% is greater than the percentage
>   of real names that are longer than N, then we're good?)
> - we STRONGLY RECOMMEND that servers choose names shorter than
>   N octets for hidden web sites
>

I am not in favor of these changes.  They reduce protocol flexibility for
servers
which know what they are doing and largely can be implemented in the
protocol
by servers which do know what they are doing.


- servers pad Certificate to a multiple of M octets (M=2000 maybe)
>

Again, this has a huge negative impact on performance and the server can
do much better if it's smart.

  and CertificateVerify to a multiple of O octets (with O=500 maybe)
>

In addition to the comments above, your number for O is way too large
if the server has effectively any information about which algorithms it is
using. Even if you know that you only use RSA-2048 (by far the dominant
size) then you can do far better than 500. Similarly, if you have the same
set of algorithms for all your domains, this does not leak any information.

-Ekr









> I'd be fine with any minor changes to the above as well
> or with another scheme that allows us to get rid of the
> ESNIKeys.padded_length field.
>
> Cheers,
> S.
>
> PS: There was a little discussion of this on github, [1] but
> I figure this is really one the WG ought deal with.
>
> [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/122
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>