[TLS] Questions about TLS Server Name Indication extension

[Nelson B Bolyard <[e-mail]>]

A few years ago, I implemented the SNI extension in a client-only TLS
library and it was really simple because I only ever sent one host name
to the server.  Now I'm implementing the server side of SNI and I realize
that the RFC appears to allow clients to do much more complex things than
my client ever did.  So, I have some questions seeking clarification about
the definition of SNI.  I hope someone here can help me by answering some
of these questions.

Q1)  A client hello's SNI extension is defined such that it may contain
multiple names.  Perhaps the intent was to allow the same server to be
named in multiple different name spaces (DNS and others), but I saw nothing
in RFC 4366 that precludes the client from naming multiple different hosts
in a single ServerNameList.  If a client names multiple host names in a
single client hello SNI extension (let's call them A.foo.com, B.foo.com and
C.foo.com) how does the client learn which one of those has been chosen by
the server?  RFC 4366 requires the "extension_data" field of the SNI
extension in the server hello to be empty.  The server may respond with a
"wildcard" certificate ("*.foo.com"), or with a certificate with multiple
Subject Alternative Names that include more than one of the names given by
the client.  In that case, how does the client know which FQDN is the one
that the physical server has chosen/identified?

I can think of lots of possible answers here, including

a) It is an error to include multiple names in the same name space, e.g.
multiple DNS names. (but the RFC doesn't say that.)

b) If multiple names are included, they must be logically synonymous, all
alternative names for the same host.  (What if they're not?)

Q2) if multiple non-synonymous names are included, is the server free to
pick any one that it wants?

Q3) Consider the "renegotiation" case, where a client and server negotiate
an initial SSL handshake ("in the clear") and then negotiate a second
handshake over the encrypted channel established by the first handshake.
Are there any special requirements or prohibitions on the use and contents
of the client hello's SNI extension in the renegotiation case?

Q3a) Is SNI permitted in that case?
Q3b) Is it required to match the SNI of the original handshake, if any?
Q3c) If it contains multiple non-synonymous host names, is the server
allowed to choose a different one than the one chosen in the first
handshake?

The next questions have to do with the "resumption" or "restart" of a TLS
session that has been previously established using an SNI extension that
named one or more virtual hosts in a connection to a physical server on
an IP address and port.

Q4) In that context, is the scope of a TLS session ID that of the physical
server, or that of a virtual server?  When attempting to restart a TLS
session on a new connection, does the TLS session ID in the client hello
uniquely identify the virtual host and its session to the physical server,
even in the absence of an SNI extension?  Or is it possible that each of
the virtual servers within the physical host may have used that same
session ID, in which case it would be necessary for the client to supply the
virtual host's FQDN in an SNI extension to uniquely identify the session?

Q5) When an SNI extension was used to establish a TLS session, it is
required that an SNI extension bearing the same host name be used in the
client hello that attempts to "restart" or "resume" the session on a new
connection?

(Obviously Q3, Q4 and Q5 overlap.)


I eagerly await your answers and comments.

/Nelson Bolyard