Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert

[Martin Rex <[e-mail]>]

Nikos Mavrogiannopoulos wrote:
> 
> Michael D'Errico wrote:
> > I agree with Yngve that a server should send either an empty SNI
> > extension OR an unrecognized_name alert but not both.  However, I
> > disagree that the server SHOULD NOT send a warning alert since that
> > hides information from the client.
> [...]
> >     1 - server understood the SNI and used it to select an appropriate
> >         certificate chain and other parameters
> >     2 - server understood the SNI but did not recognize it as one of
> >         its configured virtual hosts; however, the server is set up
> >         to use a default configuration in that case
> >     3 - server understood the SNI but did not recognize it as one of
> >         its configured virtual hosts; there is no default configuration
> >         available so the handshake can not continue
> >     4 - server does not understand the SNI extension
> > 
> > The way my server reacts to each of these cases is:
> > 
> >     1 - add an empty SNI extension to ServerHello
> >     2 - send a warning unrecognized_name alert
> >     3 - send a fatal unrecognized_name alert
> >     4 - send nothing
> > 
> > Yngve would prefer that nothing is sent in case 2, but then a client
> > can not distinguish it from case 4.
> 
> I believe that his point was, what can the client do anyway? In both
> cases the client just follows the handshake and will be prompted if the
> "default" certificate doesn't match the connected host. Would the client
> need to be warned that he is being connected using the "default"
> certificate rather than any specific?

I think the issue is much more about API semantics.

Most APIs are pretty binary, either they succeed, or they fail with
a (numeric) error code.  The case "succeeds with a warning code"
is fairly unusual for APIs, and very unusual to application programmers.

Defining non-fatal error codes might be possible, but you don't know
what exactly apps will do: will they simply ignore error codes that
are classified non-fatal or will they abort on all error codes that
they do not recognize.

And as soon as you have several software/abstraction layers in your
software architecture, the picture becomes more and more fuzzy,
because you don't know whether intermediate layers are prepared
to deal with non-fatal error codes and in particular non-fatal
error codes that were defined after the intermediate layers
were shippped.

A warning-level "unrecognized_name" alert is useful for the receiver
only when it is made available to the application on top of TLS in
a clearly defined and consistent fashion.  If we want to allow
warning-level "unrecognized_name" alerts, then we must define
the API semantics for the receiving TLS implementation that
its calling app is going to experience.  Otherwise, we should get
rid of it (and use the fatal-level alert for the situation where
the server is condigured to abort the handshake).


-Martin