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

[Martin Rex <[e-mail]>]

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.
> 
> Sometimes the only use of a protocol message is to provide information
> to a software developer who wrote the code so he has some clues to go on
> when the bug report with the protocol trace lands in his inbox.

We are discussing a network protocol here, and there we need a
_MUST_ define the semantics of a protocol signal for both, the sender
and the receipient.  Everything else is going to be an interoperability
problem (as observed by Yngve), or at least useless protocol complexity.


> 
> Although it is good to try to avoid it, the vast majority of nontrivial
> systems have failure modes that were not anticipated during development
> and testing. As a developer, I really value the ability to issue some
> opaque internal error code message into some log file. Somehow the
> system got into a state that I didn't expect it could, if I could have
> described how the system should react, I would have coded it that way.
> 
> A strict policy like "all warnings must X" just leads to the warning
> message facility being unusable for cases where X is too difficult.


This description oversimplifies the whole issue.

If there are protocol elements that convey information between to
communication peers, then the semantics of that piece of information
must be well-defined for both, sender and receipient.  Some of the
conveyed information affects the communication protocol itself,
other information is conveyed for consumption by the calling
application, not for the protocol engine itself -- such as a
warning-level alert "unrecognized_name".

It makes perfect sense to require this information be made available
_by_the_recipient_TLS_implementation_ to the receipient calling
application _somehow_ (details unspecified).  A calling application
that does care about this non-fatal information will have to retrieve it.
The calling app may decide to abort the fully established TLS session and
retry with different parameters later on.  But the TLS (client)
implementation receiving a warning-level "unrecognized_name"
alert SHOULD ignore this alert and continue the TLS handshake.
There is nothing that the receiving TLS implementation itself can do
about this warning-level alert.

Aborting on an unexpected (or even unknown warning-level TLS alert)
appears to be generally a bad idea, because it creates unnecessary
interop problems.  The IETF golden rule for protocol applies here
"be liberal in what you accept".  TLS protocol engines that
unconditionally fail when receiving unknown or unexpected
warning-level alerts (excluding those warning-level alerts that
have a well-defined protocol-engine semantic, such as close_notify)
exhibit a significant lack of robustness.


-Martin