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

[Michael D'Errico <[e-mail]>]

I would like to see text that says a peer SHOULD ignore warning alerts
that it doesn't otherwise handle.  Clearly the peer that sent the alert
with a warning level doesn't think it's a showstopper -- if it was a
problem, the alert level would have been fatal.

Peers that escalate a warning to fatal are not playing nice; they are
causing other software to abandon the practice of sending warnings even
though they could prove useful.  Just because you can't imagine why a
warning alert would be useful, today, doesn't mean that a use will never
be found for it.

Mike



Martin Rex wrote:
> Nikos Mavrogiannopoulos wrote:
>> Michael D'Errico wrote:
>>> I agree with Yngve that a server should send either an empty SNI
>>> extension OR an unrecognized_name alert but not both.  However, I
>>> disagree that the server SHOULD NOT send a warning alert since that
>>> hides information from the client.
>> [...]
>>>     1 - server understood the SNI and used it to select an appropriate
>>>         certificate chain and other parameters
>>>     2 - server understood the SNI but did not recognize it as one of
>>>         its configured virtual hosts; however, the server is set up
>>>         to use a default configuration in that case
>>>     3 - server understood the SNI but did not recognize it as one of
>>>         its configured virtual hosts; there is no default configuration
>>>         available so the handshake can not continue
>>>     4 - server does not understand the SNI extension
>>>
>>> The way my server reacts to each of these cases is:
>>>
>>>     1 - add an empty SNI extension to ServerHello
>>>     2 - send a warning unrecognized_name alert
>>>     3 - send a fatal unrecognized_name alert
>>>     4 - send nothing
>>>
>>> Yngve would prefer that nothing is sent in case 2, but then a client
>>> can not distinguish it from case 4.
>> I believe that his point was, what can the client do anyway? In both
>> cases the client just follows the handshake and will be prompted if the
>> "default" certificate doesn't match the connected host. Would the client
>> need to be warned that he is being connected using the "default"
>> certificate rather than any specific?
> 
> I think the issue is much more about API semantics.
> 
> Most APIs are pretty binary, either they succeed, or they fail with
> a (numeric) error code.  The case "succeeds with a warning code"
> is fairly unusual for APIs, and very unusual to application programmers.
> 
> Defining non-fatal error codes might be possible, but you don't know
> what exactly apps will do: will they simply ignore error codes that
> are classified non-fatal or will they abort on all error codes that
> they do not recognize.
> 
> And as soon as you have several software/abstraction layers in your
> software architecture, the picture becomes more and more fuzzy,
> because you don't know whether intermediate layers are prepared
> to deal with non-fatal error codes and in particular non-fatal
> error codes that were defined after the intermediate layers
> were shippped.
> 
> A warning-level "unrecognized_name" alert is useful for the receiver
> only when it is made available to the application on top of TLS in
> a clearly defined and consistent fashion.  If we want to allow
> warning-level "unrecognized_name" alerts, then we must define
> the API semantics for the receiving TLS implementation that
> its calling app is going to experience.  Otherwise, we should get
> rid of it (and use the fatal-level alert for the situation where
> the server is condigured to abort the handshake).
> 
> 
> -Martin
>