Re: [TLS] Issue 16: Alert clarifications

[Bodo Moeller <bmoeller at acm.org>]

On Sun, Jun 10, 2007 at 10:51:23PM +0200, Martin Rex wrote:
> Pasi.Eronen at nokia.com wrote:
>> Eric Rescorla wrote:

>>> - Add a warning that some implementations tear down the connection
>>>   for any alert so warning alerts are dangerous. New implementations
>>>   SHOULD not tear down the connection for warning alerts.

>> 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.
> 
> A fatal alert has always been "fatal" for the handshake, and
> implementations that continued after a fatal alert can be considered
> broken.
> 
> A warning alert has never been "fatal", otherwise the distinction
> into fatal and warning would be non-sensical.  It may have not been
> fully spelled out in the spec, but this is a level of implicit common
> sense that one should be able to expect from a sensible implementor.

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.

Words like this in a specification override implementor common sense.

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

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.

Bodo


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