Hiya, On 21/10/2019 19:08, Eric Rescorla wrote: > No. You want padding to be set to be the longest size that you would send > to any origin in the anonymity group, and the server knows this.
In the past, I've argued that this is not necessarily true and hence the current padding scheme is not a good plan. Two main reasons: - a server may not have visibility of all names that can be in certificate SANs - even if a server does have such visibility at time t, a CA re-issuing certs can change the situation during the lifetime of one ESNIKeys value I believe it is not unknown for servers to have a DB of TLS server certs/private keys that is queried based on the SNI (which could've arrived as ESNI). I don't know how common that is. My guess is that all of the above will lead to everyone always using 260 for this value, making it pointless and somewhat wasteful. I would argue for an algorithmic method of padding and to not require servers to include any value in ESNIKeys at all. I proposed one such algorithm on the list before. Cheers, S. PS: I think 260 is the right max, didn't look it up just now but I did some time ago and it seemed correct.
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
