Archive

Looks good.

Mike

Joseph Salowey (jsalowey) wrote:
> OK with me, so we have:
> 
> "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
> warning-level unrecognized_name(112) alert is NOT RECOMMENDED, since
> existing  client behavior is unpredictable. 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 whether 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. "
> 
> 
> 
>> -----Original Message-----
>> From: Martin Rex [mailto:mrex@sap.com]
>> Sent: Monday, June 07, 2010 3:04 PM
>> To: Joseph Salowey (jsalowey)
>> Cc: tls@ietf.org
>> Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
>>
>> 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
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 