Re: [TLS] Issue 16: Alert clarifications

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

Bodo Moeller wrote:
> 
> 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.

They can be interpreted as errors, but if the sender does not
tag them as "fatal", then they're _NOT_ fatal errors resulting
in termination of the connection.


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


The user_cancel alert is particularly fascinating in TLSv1.0
It is always a warning level alert, and the sender of this warning
should followup directly with a "close notify alert" (apparently
to perform "graceful" shutdown).

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

I firmly believe that the SSLv3 spec required it, but a spec weasel
might try to argue that the TLSv1.0 an later specs have failed to add
the proper rfc-2119 terminology to various places of the SSLv3 protocol
description and therefore relaxed the original SSLv3 requirements.

-Martin

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