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
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
