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

[Marsh Ray <[e-mail]>]

On 6/9/2010 11:37 AM, Paul Hoffman wrote:
> 
> This is definitely more understandable than earlier revs. However,
> there is still not enough definitive wording. I propose:
> 
> The ServerNameList MUST NOT contain more than one name of the same 
> name_type.  If the server understood the ClientHello extension but 
> does not recognize the server name, the server SHOULD take one of
> two actions: abort the handshake by sending a fatal 
> unrecognized_name(112) alert, or continue the handshake using a 
> default credential.

Is it necessary to specify that the continued handshake SHOULD "use a
default credential"? TLS doesn't really require handshakes to use
credentals after all.

Perhaps this is extraneous overspecification?

If not, perhaps some clarification of the meaning of this term
"default credential" would be helpful. I'm not sure if this is what was
meant, but one possible rewording might be "or continue the handshake as
if the client had not specified a server_name extension."

> Sending a warning-level alert such as 
> unrecognized_name(112), but continuing the handshake, is NOT 
> RECOMMENDED because the client's expected behavior in response to 
> this is unpredictable.

I accept that I may be in the minority on this (I honestly don't see why
this case shouldn't be considered grounds for outright handshake
failure). Still, as a guy who writes app code on the client side, the
server side, and sometimes in between it seems to me like what we're
calling "unpredictable client behavior" here is really the effect of
conscious design decisions that made by implementers of TLS libraries
and client application code.

So if a modern SNI-aware client wishes to abort the handshake on
receiving the name mismatch warning, is it really appropriate for the
revised spec to attempt to defeat that by saying the server should
withhold this information from the client and the warning SHOULD NOT be
sent at all?

- Marsh