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