Re: [TLS] Issue 16: Alert clarifications

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

Bodo Moeller wrote:
> 
> >> Why not simply "MUST NOT tear down"? (this requirement would apply 
> >> only when TLS 1.2 is negotiated, so what some implementations did
> >> with 1.0 or 1.1 doesn't matter)
> 
> > I don't undestand what should be new to this.
> 
> I used to think so too.  However, RFC 2246 and RFC 4346 both explicity
> say that
> 
>                  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.

I don't see how this changes anything.  A Server that receives a
no_certificate alert instead of a requested client SSL cert may
treat this as a fatal error as well.  But that's a determination
made by the server, and such a determination is *NOT* covered
by the peer's alert message (the peer should be waiting for
continuation of the communication/handshake).


> 
> Sometimes this actually *does* make a bit of sense, e.g. when
> receiving a certificate-related alert when you know you have to be
> authenticated for whatever you intend to do with the TLS connection;
> or if you want to insist on renegotiation.  It would make much more
> sense, though, if the party that intends to close the connection in
> response to a warning alert is required to send a fatal alert first.

This is how I understood the idea behind the seperate warning
and fatal alerts.


> Then the warning alert itself does not close the connection, and we
> have an explicit fatal alert that indicates to the other party that
> the connection will be closed.

There is one particular warning alert that terminates the currently active
SSL session (and usually, but not necessarily the connection):
the SSL close notify alert.

Reusing a (tcp) communication channel after an SSL close notify alert
is a littly tricky (making sure that there are no close notify alerts
left in the channel), but it is possible--at least if you know exactly
what the SSL implementations on both sides are doing and that they
offer a call that removes the (probably encrypted) close-notify alerts
properly.


> 
> This is what my proposal would achieve:
> 
>    If an alert with a level of warning is sent and received, generally
>    the connection can continue normally.  If the receiving party
>    decides not to proceed with the connection (e.g., after having
>    received a no_renegotiation alert that it is not willing to
>    accept), it MUST send a fatal alert to terminate the connection.
> 
> Nelson has suggested spelling out that fatal alerts should be required
> for all fatal errors, which makes sense too.  That is, anytime a
> party closes the connection because of whatever error, it should send
> a fatal alert unless it has already sent or received one, or unless
> it is impossible to send anything.


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.


-Martin

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