On Mon, Oct 21, 2019 at 11:41 AM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > 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 > The question is not the server, but the operator. - 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 don't agree that 260 is pointless, though perhaps 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. > Yes, but I do not believe that it obtained the consensus of the WG. Obviously, if the chairs call consensus on this point, we will change the draft. -Ekr > 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. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
