Re: [TLS] Issue 16: Alert clarifications

[Martin Rex <Martin.Rex at sap.com>]

Bodo Moeller wrote:
> 
> On Tue, Jun 12, 2007 at 05:26:41AM +0200, Martin Rex wrote:
> > Bodo Moeller wrote:
> 
> >> This has nothing to do with RFC 2119 terminology.  RFC 2246 and later
> >> make specific statements regarding what the sender and receiver of an
> >> alert should do; this is where the RFC could have codified, in
> >> whatever form, this aspect of the distinction between fatal alerts and
> >> warning alerts.  It quite clearly doesn't say what we think it should
> >> be saying.
> 
> > I disagree.  Search rfc2246 for "close" of the connection, and every
> > occurrence except for "Closure alert" explicitly references a prior
> > fatal ssl alert.
> > 
> > I don't see where the spec would permit or even suggest closure of 
> > the connection after any other ssl alert of level warning other than
> > "closure alert".
> 
> The problematic language is the following:
> 
>    [...]         if an alert with a level of warning is received, the
>                                              ^^^^^^^^^^^^^^^^^^^
>    receiving party may decide at its discretion whether to treat this as
>                                                            ^^^^^^^^^^^^^
>    a fatal error or not. However, all messages which are transmitted
>    ^^^^^^^^^^^^^

Where is the problem.  The receiver which treats a warning as a fatal
error is the "detecting" party:

                                                               When an
   error is detected, the detecting party sends a message to the other
   party. Upon transmission or receipt of an fatal alert message, both
   parties immediately close the connection.

and therefore required to send a fatal alert before being allowed
to close the communication channel.


>    with a level of fatal must be treated as fatal messages.
> 
> This isn't strictly inconsistent with your interpretation, but doesn't
> enforce it either: It is easy to read this as "when receiving a
> warning alert, you may act as if you received a fatal alert".

No, this is wrong.

When receiving a warning alert, the receiving party may decide to handle
this to be a fatal error, resulting in a requirement to send a (fatal alert)
message to the other party.

The sender of the warning certainly didn't mean this to be a (fatal) error,
which is why it sent a warning and is waiting for a response/continuation
of the communication.


>
> Again, this is not what I *want* the specification to say or how I would
> like implementations to behave -- I just want the specification to say
> *more explicitly* that a party that receives a warning (other than
> close_notify) and decides to terminate the connection needs to send a
> fatal alert.

I would also appreciate if the spec was more explicit about this,
and in particular I do *NOT* want this to be considered a change
to the existing spec that is new and valid only for TLSv1.2.

Documenting what a correct sender ought to do is fairly easy.
Documenting what behaviour receipients will have to deal with in
the wild is much harder, because of inconsistencies, defects and
silent backwards-incompatible changes in the history of the TLS spec.

> 
> Maybe that's already what RFC 2246 secretly wanted us to do, but if
> so, it is not revealing much about this.  For example, you have to be
> creative about determining the appropriate error alert for this fatal
> alert: From the alert descriptions in RFC 2246, there isn't really
> anything appropriate for every case -- what do you send when
> terminating the connection in response to, say, a bad_certificate
> warning?  Using bad_certificate for the response too can be ambiguous;
> unexpected_message isn't appropriate for this according to the
> specification ("should never be observed in communication between
> proper implementations"); so handshake_failure possibly is the best
> choice, but this use doesn't quite match its description in the RFC
> (according to the spec, it is about unacceptable "security
> parameters", and that's a pretty specific term in the TLS
> specification: see 6.1 and A.6).

The spec calls for a fatal handshake_failure alert in most situations.
Which, admittedly, isn't going to be very helpful for the peer. :-|


> 
> This would be quite different if there was any error alert description
> that said something along the lines of "This alert is sent if a
> warning alert is received and this warning is treated as an error.
> This message is always fatal."  (Maybe something like this should be
> added to the handshake_failure description.)

It seems strange that there are several alerts in SSL concerning certificate
validity/acceptance and even one to indicate that no (client) certificate
is available, but none for indicating certificate_required.


There was a warning alert added to TLSv1.0 in an IMHO broken fashion:
user_cancelled.  rfc2246 even suggest that this is followed up by
a close notify alert -- which I consider a serious mistake.

user_canelled should have been made an alternative "closure alert",
if any.

"close notify" only makes sense after a successfully completed SSL/TLS
handshake, it would be inappropriate during the SSL/TLS handshake.
for fully established SSL/TLS sessions.

"user_cancelled" was apparently added to perform a "graceful abort"
of a SSL/TLS handshake (probably with the intention that it does
not get logged or reported as a technical error).  As such, the
suggestion to followup with a close_notify is IMHO wrong.
close notify should only be used after a successful handshake.


-Martin








_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls