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

[Marsh Ray <[e-mail]>]

On 6/4/2010 1:47 PM, Martin Rex wrote:
> Marsh Ray wrote:
>>
>> On 6/4/2010 11:47 AM, Martin Rex wrote:
>>>
>>> But defining only the situation when one peer can send a particular
>>> warning level alert is entirely insufficient.  The definition of
>>> a warning-level alert _MUST_ describe how the receiving peer is
>>> supposed to react to this.
>>
>> I don't agree with such an absolute statement.
>> [...]
> 
> It seems that I wasn't clear enough in my description.
> 
> This must first of all describe how the implementor of the technology TLS
> must make this information available to the consumer of the
> technology/implementation (i.e. the application caller).
> 
> This is similar of how an implementation of TCP must exihibt specific
> semantics to the application caller on receipt of certain TCP flags,
> e.g. the TCP PUSH flag.
> 
> If the spec does not describe this, then it may result in either getting
> entirely ignored--at which point it is useless complexity in the spec,
> or result in unnecessary interop problems, i.e. if a client unconditionally
> abort receiving a warning-level unrecognized_name alert.  In both cases
> such a (mis-)feature would have to be stripped when advancing the spec
> to draft, so there is no point including it in the spec in the first place.

OK, I'll buy that at the level of "should" but not at "_MUST_", if that
makes any sense.

Part of the value in using a separate library with a defined API is that
it reduces the number of states and failure modes that the application
code has to consider. It's exactly like object-oriented encapsulation
which allows the scary mechanical guts of an implementation to be hidden
behind a relatively simple interface. In reality, application code often
deals with TLS connections through the same interface as regular TCP
socket connections. This is great, as long as it's not an
oversimplification of what is really complicated.

As both a "casual user" and occasional "power user" of networking APIs,
I rely on having the option of working with every little detail of the
protocol when I need it. Making an API (or set of APIs) that satisfy
everyone is a real art!

Nevertheless, the vast majority of application code seems to have a
choice of two options when encountering an exceptional condition:

   1. Ignore it and continue as if nothing is wrong.
   2. Abort the operation and propagate the error up to the caller.

In relatively rare cases, a third option is:

   3. Change something (e.g. wait some time) and retry.

Since all of these options require truly non-trivial implementation on
the application side in order to result in a robust system, mandating
application behavior as part of a protocol spec may be asking a bit much.

This is a data security protocol after all and the handshake should
"fail to succeed" if the endpoint identities don't match up right.

IMHO Language like "if the server refuses to continue" should be avoided
in this kind of spec. It's the job of the spec to specify whether the
server should continue or terminate because it is or isn't safe, so in a
sense this warning is just pushing the hard decisions onto the library
and application.

When faced with a 'warning'-like condition, we should try really hard to
define it to be either a fatal error or a success (though possibly with
informational-level messages).

In most cases the name on the certificate would serve to eliminate any
confusion, but there are wildcard certs in use too.

I'm sorry if I missed this in earlier discussion, but why on earth would
an SNI-aware server ever want to continue a handshake with a client that
asked for a name he didn't serve?

A simple solution seemed to work for session resumption:

>From http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-08 :
>    A server that implements this extension MUST NOT accept the request to
>    resume the session if the server_name extension contains a different
>    name.

Can we just define this situation as a fatal handshake error and be done
with it?

- Marsh