On Mon, Oct 21, 2019 at 1:46 PM Stephen Farrell <stephen.farr...@cs.tcd.ie>
wrote:
>
> 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.
>
Fortunately, we have a number of such operators on this list. Alessandro?
McManus? Nygren, What say you?
-Ekr
("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.
>
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
