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

[Martin Rex <[e-mail]>]

Joseph Salowey wrote:
> 
> OK, here is some new suggested text.  Let me know if you can live with
> this.  
> 
> "The ServerNameList MUST NOT contain more than one name of the same
> name_type. If the server understood the client hello extension, but
> refuses to continue because it does not recognize the server name, 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 existing  client behavior is unpredictable.  A client that
> receives a warning-level unrecognized_name(112) alert SHOULD ignore this
> alert and continue the TLS handshake, which may fail as a result of a
> name mismatch.  The warning MAY be logged as part of diagnostic
> information recorded for a failed handshake."


I am fine with what I think is the intention of this wording,
but I would actually appreciate to be more specific about what
"may fail as a result of a name mismatch" applies to exactly.

                                                     A TLS client
  implementation that receives a warning-level unrecognized_name(112)
  alert SHOULD ignore this alert and continue the TLS handshake.
  If there is a mismatch between the server name used by the client
  application and the server name of the default credential chosen
  by the server, this mismatch will become apparent when the client
  application performs the server endpoint identification, at which
  point the client application will have to decide wether to proceed
  with the communication.  TLS implementations are encouraged to
  make information available to application callers about warning-level
  alerts that were received during a TLS handshake. Such information
  can be useful for diagnostic purposes.


-Martin