Re: [TLS] Issue 16: Alert clarifications

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

Bodo Moeller wrote:
> 
> Martin Rex wrote:
> > 
> > The description of Error (alerts) in SSLv3 (Nov.96) says this:
> > 
> >   5.4.2 Error alerts
> > 
> >      Error handling in the SSL Handshake protocol is very simple.  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.  Servers
> >      and clients are required to forget any session-identifiers, keys,
> >      and secrets associated with a failed connection.  The following
> >      error alerts are defined:
> > 
> > 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.  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.


At most, the TLS spec failed to adopt the correct spec terminology
when copying the SSLv3 text.  IMHO it has always been fairly obvious
what correct implementations are supposed to do.


-Martin

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