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

[Nikos Mavrogiannopoulos <[e-mail]>]

Michael D'Errico wrote:
> Martin Rex wrote:
>>
>> I actually fail to see the exact purpose of a warning-level alert
>> "unrecognized_name".  The client is supposed to perform the server
>> endpoint
>> identification in any case, and that warning should not affect the
>> outcome of that process at all.
> 
> I feel like I'm "guilty until proven innocent" on this one.
> 
> Have you ever connected to a secure site only to have the HTML contain a
> warning that inadequate security was established?  This used to happen
> if you connected to www.paypal.com with DES3 (but now it is just closing
> the connection).  The purpose of that behavior was to give the end user
> more diagnostic information than they get when the connection is merely
> dropped after sending a fatal handshake_failure alert.

TLS doesn't handle this. TLS doesn't even specify a security level for a
connection (and it isn't easy to).

> It would help if a no_common_ciphers alert was added to TLS.  That alert
> would be sent when the server doesn't support any of the client's
> proposed cipher suites.  It could also be used at the warning level in
> the case of paypal's former behavior.  The handshake would complete
> (after sending the warning)

How would it complete if they don't have common ciphers?

> 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.

For the current example it is obvious what went wrong by viewing the
certificate sent isn't it?

> 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 think it is important to have a good case of a thing to be handled in
code. If a TLS warning alert is _never_ going to be used, or it does not
provide valuable information to the peer. However if you think that this
information is valuable and it might even save debugging time for
implementors then I think it would be a nice opportunity to reconsider
(at least for me). Otherwise I think that the information provided by
this alert is redundant since it can be also seen by the certificate sent.

regards,
Nikos