On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > 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. > I don't believe that this claim is correct in general. Remember that these records are stored in the DNS under the name that becomes the SNI, so, absent wildcards, ths eet of names is in fact known, regardless of what happens to be in the certificate. > 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. IIRC it was there at the time of adoption. -Ekr 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. > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
