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

["Joseph Salowey (jsalowey)" <[e-mail]>]

<snip>
> 
> It should be in both places, especially since there won't be another
> update to the main spec for several years.
> 
[Joe] 4366-bis does not update 5246.  Right now we need to focus on
resolving this issue for SNI so we can get the document out. 

> 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