Re: [TLS] Issue 16: Alert clarifications

[Bodo Moeller <bmoeller at acm.org>]

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
   ^^^^^^^^^^^^^
   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".  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.

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).

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.)

Bodo


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