Subject: [TLS] ESNI tunnel version - nonce/padding

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Jan 2020 19:56:04 +0000

Hiya,

I've started to code up a guess as to how the tunnel
or encrypted client hello version of ESNI [1] might
look like in the future draft-06.

Note that my branch [2] doesn't actually work yet, and
embeds a bunch of guesses as to what draft-06 might
include, so mega-caveats apply:-)

As you'd expect the encrypted CH code is a bit messy
but so far (client-side mostly done, server-side
done to the point of decrypting the inner CH) the
tunnel approach seems fairly doable with OpenSSL.

One protocol change I'd suggest from coding so far
(compared with the draft PR [1]) is to combine the
esni_nonce and ESNI-specific padding into one thing,
being a nonce that's at least 16 octets long but that
ought be padded to the length as determined by
ESNIConfig.

At least in OpenSSL, that'd be a good bit easier to
handle, compared to having a fixed length nonce in
one extension and then modifying whatever a caller
has asked for in the padding extension (possibly via
a callback). It should also result in fewer octets
overall in the default case, which seems better. But
it's the possibly unexpected change in behaviour
vs. an application callback that's the real argument
for this.

I don't much care if the esni_nonce extension would
have all random octets or 16 random and then zero
valued octets for padding, but all-random seems easier
and less error-prone.

If that makes sense I can whack in a comment to
github so it doesn't get forgotten.

Cheers,
S.

[1] https://github.com/tlswg/draft-ietf-tls-esni/pull/196/files
[2] https://github.com/sftcd/openssl/tree/encch