Hiya, On 21/10/2019 20:29, Eric Rescorla wrote:
> The question is not the server, but the operator. Sure, but the point holds though. If ESNIKeys are changed every N seconds, and any new certificate is loaded during that time, then the server operator can't tell the lengths that the CAs might produce in future. So with the current design 260-always is the only thing a server-operator (or really an ESNIKeys generator who may be a slightly different entity) can rely on in general. > Yes, but I do not believe that it obtained the consensus of the WG. Not yet, that's true. OTOH, the 260 value wasn't decided on the list either that I recall. However, I'm not objecting to the current design for process reasons at all, I'm only critical of it technically:-) > Obviously, if the chairs call consensus on this point, we will change the > draft. Sure. We'll see where it lands. I remain hopeful a better design will be the result. S.
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
