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

[Michael D'Errico <[e-mail]>]

[I'm resending this message since it never made it to the list
the first time.  --Mike]

--- Begin Message ---

Nikos Mavrogiannopoulos wrote:
> Michael D'Errico wrote:
>> 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.  
> 
> This wording however suggests that at a later time it might be good to
> send this alert with warning level. I agree with Martin here, that if a
> warning level alert is to be sent then it's purpose should be well
> defined. Otherwise it just increases complexity, without actual benefit.

I have already shown when a warning alert makes sense.  If a server
doesn't recognize the name but is willing to continue with the handshake
anyway (using a default configuration), it can alert the client to this
fact by sending a warning alert.  It is NOT fatal.  You and others want
to suppress this piece of information, which I believe could be useful.
So that's why my text suggests that in the future this alert might be
good to send with a level of warning.

>>     New software is encouraged
>>     to treat warning alerts as informational, and not to abort
>>     an otherwise legitimate handshake.
> 
> I believe this is too much for an extensions document. If wording like
> this is to be adopted it should be in the main TLS document.

It should be in both places, especially since there won't be another
update to the main spec for several years.

The problem seems to be that the names given to alert levels both sound
bad.  Really what they mean are "fatal" and "non-fatal" but since the
name "warning" was chosen as the label, implementers who haven't thought
much about it decide that warning == bad, so they escalate it to fatal.

They need to be told that warning alerts should not automatically be
treated as fatal, but should be ignored by default.  If they have gone
through an analysis and determined that a particular warning alert is
really fatal for them, then they are justified in aborting the handshake
when they see that particular warning.

> My version of how the text should be is:
> 
> (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.
> The server might decide to continue the  handshake, but in that case it
> is NOT RECOMMENDED send any warning alert. Clients SHOULD be prepared to
> receive and ignore the unrecognized_name(112) alert with warning level.

I could live with this text.  I would also like section 9 (Error Alerts)
to mention that warning alerts should be treated as informational (non-
fatal) by default to help avoid similar problems in the future.

Mike

--- End Message ---