Re: [TLS] Issue 16: Alert clarifications

[Bodo Moeller <bmoeller at acm.org>]

On Tue, Jun 12, 2007 at 01:26:34AM +0200, Martin Rex wrote:
> Bodo Moeller wrote:
>> Martin Rex wrote:

[...]
>>> A no_certificate alert sent by an SSL/TLS client is not an error,
>>> it is a protocol option requested by the server and rejected by the
>>> client.  If the server considers this an error "the detecting party
>>> sends a message to the other party."  If that message is a fatal
>>> alert, the communication ends.  If the peer simply closes the
>>> communication channel without sending the required (alert) message
>>> it is defective.

>> Here you are mixing levels: the no_certicate alert *is* defined in
>> the "Error Alerts" section, so technically this *is* an "error" --
>> at least in the sense of "error" that the sentence that you quote
>> is assuming.

> Carefully read the "Error alerts" (which is present in TLS 1.0 as well)
> again.
> 
> The two important points there are
> 
>  1)  "When an error is detected, the detecting party sends a
>       message to the the other party".
> 
>  2)  "upon transmission or receipt of a(n) fatal alert message,
>       both parties immediately close the connection."
> 
> In error situations, the connection is terminated after transmission
> or receipt of a fatal alert message.  The party that "detects" the
> error (i.e. the party that wants to abort the handshake) sends a
> (fatal alert) message to the other party.
> 
> For me, that is equal to a "MUST send fatal alert before closing
> the connection" in error situations.

This is what it means to you because this makes SENSE, not because it
has been WRITTEN DOWN in the spec :-)

>                                       Graceful shutdown uses
> close notify (warning) alerts.
> 
> The "no_certificate" and "no_renegotiation" message, when sent as
> warning (not as fatal) are definitely not errors, they just happen
> to share the same messaging primitive (SSL alert) and are therefore
> described in this section as well.

They are not errors to you, but they are errors in the terminology
of at least the TLS 1.0 spec, and arguably also the SSL 3.0 spec.
Remember that not only this is the "Error alerts" section, but
also that RFC 2246 states that

   For all errors where an alert level is not explicitly specified, the
       ^^^^^^^^^^          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   sending party may determine at its discretion whether this is a fatal
                                                 ^^^^^^^^^^^^^^^^^^^^^^^
   error or not; 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.

According to this, there can be non-fatal errors -- in other words,
warnings are still "errors" in the terminology employed by the
specification.

Of course, I totally agree that it makes sense to require fatal alerts
before the connection is torn down (except in the close_notify case,
obviously), and that it makes a lot of sense for implementations of
the current specs to behave like this.  I just don't agree that the
current specifcations already require implementations to do this.

Bodo



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