On Mon, Jan 6, 2025 at 9:31 PM Watson Ladd <watsonbl...@gmail.com> wrote:
> On Mon, Jan 6, 2025 at 6:14 PM Eric Rescorla <e...@rtfm.com> wrote:
> >
> >
> >
> > On Mon, Jan 6, 2025 at 11:31 AM Michael Richardson <
> mcr+i...@sandelman.ca> wrote:
> >>
> >>
> >> Please note and respect the Reply-To: u...@ietf.org.
> >>
> >>
> >>
> >> 4. Find a sensible way to extend RFC6066 to accomodote other forms of
> SNI.
> >> There isn't an IANA registry for this.
> >
> >
> > Just as a technical matter, it's not really possible to extend RFC 6066
> because there
> > is no way to skip past unknown name types. This is a bug, but it's a bug
> we're stuck
> > with.
> >
> > struct {
> > NameType name_type;
> > select (name_type) {
> > case host_name: HostName;
> > } name;
> > } ServerName;
> >
> > enum {
> > host_name(0), (255)
> > } NameType;
> >
> > opaque HostName<1..2^16-1>;
> >
> > struct {
> > ServerName server_name_list<1..2^16-1>
> > } ServerNameList;
> >
> > Note that the only length field is in HostName, which means that you
> don't know how
> > long the length field is in other NameTypes, so you can't ignore them.
> If this is
> > the general route you want to take, you'll need a new extension.
>
> Implementations might choke on any new name type alas, but there's no
> reason from a wire perspective we couldn't say all names are
> <1..2^16-1>
>
We could have in the past, but we can't really now, because existing
servers don't
know that we've done it, so it will not be safe to send other variants in
SNI. I agree
it's unfortunate, but it's not really expensive to mint a new extension.
-Ekr
> >
> > -Ekr
> >
> > _______________________________________________
> > TLS mailing list -- tls@ietf.org
> > To unsubscribe send an email to tls-le...@ietf.org
>
>
>
> --
> Astra mortemque praestare gradatim
>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
