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

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> The unrecognized_name warning alert can provide similar information to a
> client application.  If something goes wrong and the client application
> is looking for a reason why, it can ask the TLS layer if anything strange
> happened.  If this warning alert was received, that information might
> help the client diagnose the problem and determine what corrective action
> to take.
> 
> However I disagree with your wording:
> 
>     A client that receives a warning-level "unrecognized_name" alert
>     SHOULD ignore this alert and continue the TLS handshake.  The purpose
>     of a warning-level "unrecognized_name" is for diagnostic purposes,
>     if anything.
> 
> Clearly you don't see much use for this alert, but you should not impose
> that bias on others.  It is up to the application to decide what to do
> with the facilities provided by the TLS protocol.

I am sorry for again being ambiguous in my descriptions.

This wording is supposed to apply to >>TLS client implementations<<,
and these are supposed to completely ignore warning-level alerts and
continue the TLS handshake.  Whether or not the resulting TLS session
characteristics meet the expectations or policy of the calling application
is an entirely different matter and up to the application to decide.

The client application can do _nothing_ useful with a warning-level
alert "unrecognized_name" other than show it to a user or write it
to a logfile.  In both situations, it MUST NOT stall the ongoing
handshake, but instead either abort (sending a fatal handshake alert)
or ignore and continue this handshake.

A non-negligible amount of the installed base of browsers (~50%) and
programmatic clients is not going to send an extension SNI, so servers
will likely have to provide something sensible for that situation anyway,
and for quite some time to come -- entirely without that alert.


-Martin