Hi,
On Mon, Jan 6, 2025 at 9:31 PM Watson Ladd < <mailto:watsonbl...@gmail.com> watsonbl...@gmail.com> wrote: On Mon, Jan 6, 2025 at 6:14 PM Eric Rescorla <e...@rtfm.com <mailto:e...@rtfm.com> > wrote: > > > > On Mon, Jan 6, 2025 at 11:31 AM Michael Richardson <mcr+i...@sandelman.ca > <mailto:mcr%2bi...@sandelman.ca> > wrote: >> >> >> Please note and respect the Reply-To: u...@ietf.org <mailto: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. Hmm, RFC 6066 actually says: For backward compatibility, all future data structures associated with new NameTypes MUST begin with a 16-bit length field. In my reading of this requirement, it allows servers to effectively skip unknown Name Types. Am I missing something? Regards, Valery. -Ekr > > -Ekr > > _______________________________________________ > TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org> > To unsubscribe send an email to tls-le...@ietf.org > <mailto:tls-le...@ietf.org> -- Astra mortemque praestare gradatim
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
