[TLS] ESNI and padding

[Stephen Farrell <[e-mail]>]

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
- servers pad Certificate to a multiple of M octets (M=2000 maybe)
  and CertificateVerify to a multiple of O octets (with O=500 maybe)

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