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

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> Joseph Salowey (jsalowey) wrote:
> > 
> > (1) "The ServerNameList MUST NOT contain more than one name of the same
> > name_type. If the server understood the client hello extension, but does
> > not recognize the server name, and it refuses to continue it MUST send a
> > fatal unrecognized_name(112) alert and terminate the handshake.  If the
> > server decides to continue the  handshake, sending a
> > unrecognized_name(112) alert with a warning level is NOT RECOMMENDED,
> > since the  client behavior is unpredictable.  Some clients respond by
> > aborting the handshake while others allow it  to continue to certificate
> > validation, which may fail as a result of a name mismatch. "
> 
> I prefer the above text, but would modify it slightly:
> 
>      If the server decides to continue the handshake, sending an
>      unrecognized_name(112) alert with a warning level is NOT
>      RECOMMENDED at this time due to legacy client software that
>      escalates it to a fatal error.  New software is encouraged
>      to treat warning alerts as informational, and not to abort
>      an otherwise legitimate handshake.


Technically, there is no such thing as an "escalation to a fatal error",
so this exact wording is inappropriate.

If a TLS peer decides to abort the handshake when receiving a warning-level
alert, that TLS peer  SHOULD send a fatal alert before closing the
connection.

When receiving a fatal-level alert, there is nothing else to send back
(the TLS peer will _NOT_ read this anyway, and there may even be unread
handshake message still in the incoming network pipe of the TLS peer
that sent the fatal alert).

-Martin