Re: [TLS] Server name extension extensibility problem

["Pasi.Eronen at nokia.com" <Pasi.Eronen at nokia.com>]

Good catch! 

I think this could be solved by requiring that all future
name types start with two-byte length field (same as
host_name), so implementations would be able to skip 
past it.

Best regards,
Pasi 

> -----Original Message-----
> From: tls-bounces at ietf.org [mailto:tls-bounces at ietf.org] On 
> Behalf Of ext Mike
> Sent: 07 May, 2008 18:03
> To: tls at ietf.org
> Subject: [TLS] Server name extension extensibility problem
> 
> Hi,
> 
> The server_name extension contains a ServerNameList, where:
> 
>    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;
> 
> The text states that this may be extended in the future to
> other name types, but I don't think that would be possible.
> 
> Suppose you were to add a new NameType and define a new
> structure to hold the name.  Software that doesn't know
> about the new name type won't know how to skip past it
> while parsing the server_name_list, since ServerName is
> currently only fully specified for a host_name.
> 
> I suppose you could restrict server_name_list to list the
> ServerNames in order (host_name first, then the next-
> defined name type, and so on), so software could simply
> stop decoding once it encounters a type it doesn't know
> about, but it's probably too late to do that since there
> is already an installed base.
> 
> Mike
> _______________________________________________
> TLS mailing list
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls