Hiya, On 21/10/2019 21:02, Eric Rescorla wrote: >> 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.
Depends which "in general" is more general I guess.
Wildcards do exist in the DNS, though TBH I'm not really
familiar with how they're implemented in authoritatives.
But even ignoring those, deployment models where the
ESNIKeys are generated by the TLS server operator, but
DNS records are published by a different entity (say the
owner of the name or registrar) ought not be precluded
I think. Supporting such a model I think more or less
requires setting padding_length to 260 or else risking
a failure nobody will notice (if browsers fall back to
cleartext SNI) or know how to diagnose if they do.
And even in the case of a monolithic service that does it
all for every name, I think it'd still likely pick 260
in order to avoid having to exercise/write the code to
detect and react to a need to increase the padding_length.
("Holy crap - you mean I need to re-publish everyone's
ESNIKeys just because this bozo has a really long name?
Who made that up?")
I really can't see what'd motivate anyone to publish
ESNIKeys with a padding_length < 260 tbh (well, other
than not having thought it through;-). Anything <260
just seems to be asking for later problems.
S.
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
