Subject: [TLS] Issue 16: Alert clarifications

From: Eric Rescorla <[email-masked]>
Date: Sun, 03 Jun 2007 07:57:30 -0700

http://www3.tools.ietf.org/wg/tls/trac/ticket/16

Several people have raised the issue of what alerts must be fatal
and when they should be sent. NIST suggested that all fatal alerts
MUST be sent. They also suggested that the following alerts be fatal:

- bad_certificate, 
- unsupported_certificate
- certificate_revoked.
- certificate_expired

We discussed this in Prague and looking at the minutes, it looks
to me like the resolution was as follows:

- All fatal alerts MUST be sent
- For the above alerts, if you plan to tear down the connection
  on that basis you MUST make them fatal and send them
- 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.

Anyone disagree with this?

-Ekr

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 3 Jun 2007 15:54:13 -0700

>Anyone disagree with this?

I may be mistaken, but I thought there were comments to the effect of 
"implementations MUST NOT tear down connections based only on a 
warning". That's different than what you have in the last clause.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nelson B Bolyard <[email-masked]>
Date: Sun, 03 Jun 2007 17:12:15 -0700

>   SHOULD not tear down the connection for warning alerts.

Why not require that a fatal alert be sent any time that the connection
is going to be torn down due to a protocol error of any kind?
That is, any time an error occurs in the TLS protocol which is severe
enough that the connection will be terminated, send a fatal alert first.
This would greatly improve diagnosis of problems.

-- 
Nelson B

---

From: <[email-masked]>
Date: Thu, 7 Jun 2007 15:33:13 +0300

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

Best regards,
Pasi

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 07 Jun 2007 06:29:18 -0700

> with 1.0 or 1.1 doesn't matter)

Works for me.

-Ekr

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 07 Jun 2007 20:33:11 -0700

>> with 1.0 or 1.1 doesn't matter)

Umm. Some warning alerts exist to give the recipient a choice to tear
down or not.  E.g. no_renegotiation.  RFC 2246 says:

   no_renegotiation
       Sent by the client in response to a hello request or by the
       server in response to a client hello after initial handshaking.
       Either of these would normally lead to renegotiation; when that
       is not appropriate, the recipient should respond with this alert;
       at that point, the original requester can decide whether to
       proceed with the connection. One case where this would be
       appropriate would be where a server has spawned a process to
       satisfy a request; the process might receive security parameters
       (key length, authentication, etc.) at startup and it might be
       difficult to communicate changes to these parameters after that
       point. This message is always a warning.

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 8 Jun 2007 10:35:14 +0200

>        point. This message is always a warning.

Good point.  This means that neither "SHOULD NOT" nor "MUST NOT" works
for everything.  However, I think a party should not silently tear
down the connection after receiving a no_renegotiation alert that it
does not like -- instead, it should send a fatal alert first.

How about the following?

   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.

---

From: Martin Rex <[email-masked]>
Date: Sun, 10 Jun 2007 22:51:23 +0200 (MEST)

> 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 know there are broken implementations out there, and I would appreciate
if they are fixed sooner rather than later, and independent of whether
they add TLS v1.2 or not.  There is one pretty large installed base
that doesn't send any alert in most situations, and I find that highly
annoying.  Combined with a Web-Browser that produces that same
meaningless error message for >95% of the possible errors (including
connection timeout and connection refused), this makes
diagnosing SSL/TLS configuration errors pretty difficult.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Sun, 10 Jun 2007 19:52:31 -0700

>    accept), it MUST send a fatal alert to terminate the connection.

I don't object to that, except that it changes TLS so that SOME fatal
errors MUST be accompanied with a Fatal Alert (as opposed to being
torn down silently), but others are not required to do so.  This begs
the question: why should some fatal errors require a fatal alert,
but not others?

> is going to be torn down due to a protocol error of any kind?

I still think that deserves an answer.

-- 
Nelson B

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 11 Jun 2007 07:36:36 +0200

>> is going to be torn down due to a protocol error of any kind?

Yes, this makes sense -- anytime a party has to abort the connection
because of some protocol error, it should send a fatal alert if
possible.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 11 Jun 2007 07:49:08 +0200

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

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

---

From: Martin Rex <[email-masked]>
Date: Mon, 11 Jun 2007 22:41:17 +0200 (MEST)

>    receiving party MAY decide at its discretion whether to treat this as

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

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

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

> 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

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 12 Jun 2007 00:27:11 +0200

> continuation of the communication/handshake).

I'm not sure what your point is here: We had suggestions to add some
"SHOULD NOT tear down the connection for warning alerts" rule to the
specification, or even "MUST NOT tear down"; you said you didn't
understand what should be new to this; and in response I pointed to
the above language that isn't consistent with "SHOULD NOT tear down"
or "MUST NOT tear down": that's why "SHOULD NOT tear down" or "MUST
NOT tear down" would be new.

> the SSL close notify alert.

True.  The above language ("if an alert with a level of warning is
received ...") is from the "Error Alerts" subsection of the "Alert
Protocol" subsection, which covers any alerts besides the close_notify
alert, so that's actually what the proposal is meant for.

> communication channel without sending the required (alert) message

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.

Actually it seems that our ideas on how the protocol should behave
with regards to alerts agree mostly (or even completely).  The main
problem apparently is that there are many things that the
specification doesn't spell out clearly -- they are left to common
sense, and occasionally there are different ways to interpret the few
details that the specification does spell out that yet, when applying
common sense, can lead to the same result.

Bodo

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jun 2007 01:26:34 +0200 (MEST)

Bodo Moeller wrote:
> Martin Rex wrote:

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

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 12 Jun 2007 01:42:09 +0200

>> Martin Rex wrote:

[...]

> 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

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

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jun 2007 02:01:21 +0200 (MEST)

> described in this section as well.

I should have written "ssl alert" instead of "message".

When I just compared SSLv3 and TLSv1 I realized subtle differences
that are not listed as (backwards incompatible) changes to the spec.

A list of changes from SSLv3 -> TLSv1.0 -> TLSv1.1 -> TLSv1.2
seems to be missing badly from the existing documents.

SSLv3 still had a "no_certificate" (warning) alert, which has evaporated
without traces from TLSv1.0.  Instead, TLSv1.0 allows an empty
certificate list in (server and) Client Certificate message, something
that was _NOT_ permitted in SSLv3.

I also noticed that the Certificate Request message was silently changed
from TLSv1.0 to TLSv1.1, suddenly permitting an empty list of DNames
(which is _NOT_ permitted in SSLv3 and TLSv1.0)

Acutally, I quite dislike this latter feature because it will be
annoying to users with multiple client certs if automatic selection
of a matching cert is impossible.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jun 2007 02:15:51 +0200 (MEST)

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

>    For all errors where an alert level is not explicitly specified, the

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

> 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

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 12 Jun 2007 02:37:26 +0200

> description and therefore relaxed the original SSLv3 requirements.

This has nothing to do with RFC 2119 terminology.  RFC 2246 and later
make specific statements regarding what the sender and receiver of an
alert should do; this is where the RFC could have codified, in
whatever form, this aspect of the distinction between fatal alerts and
warning alerts.  It quite clearly doesn't say what we think it should
be saying.

(The SSL 3.0 specification is different mostly in that it doesn't
discuss this issue in that much detail, thus leaving more space for
common sense.)

Bodo

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jun 2007 05:26:41 +0200 (MEST)

> warning alerts.  It quite clearly doesn't say what we think it should

I disagree.  Search rfc2246 for "close" of the connection, and every
occurrence except for "Closure alert" explicitly references a prior
fatal ssl alert.

I don't see where the spec would permit or even suggest closure of 
the connection after any other ssl alert of level warning other than
"closure alert".

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Mon, 11 Jun 2007 22:30:41 -0700

> description and therefore relaxed the original SSLv3 requirements.

And in fact, one of the top 10 most-used TLS implementations (one of
the newer ones) does not send fatal alerts (at least, not for most
errors), citing just that reason.

I see this becoming a nightmare for people who must diagnose problems.
I'm afraid it's too late for TLS 1.0 and 1.1 already, but I sure would
like to see it fixed in 1.2.

-- 
Nelson B

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 12 Jun 2007 11:32:35 +0200

> the connection after any other ssl alert of level warning other than

The problematic language is the following:

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

This isn't strictly inconsistent with your interpretation, but doesn't
enforce it either: It is easy to read this as "when receiving a
warning alert, you may act as if you received a fatal alert".  Again,
this is not what I *want* the specification to say or how I would like
implementations to behave -- I just want the specification to say
*more explicitly* that a party that receives a warning (other than
close_notify) and decides to terminate the connection needs to send a
fatal alert.

Maybe that's already what RFC 2246 secretly wanted us to do, but if
so, it is not revealing much about this.  For example, you have to be
creative about determining the appropriate error alert for this fatal
alert: From the alert descriptions in RFC 2246, there isn't really
anything appropriate for every case -- what do you send when
terminating the connection in response to, say, a bad_certificate
warning?  Using bad_certificate for the response too can be ambiguous;
unexpected_message isn't appropriate for this according to the
specification ("should never be observed in communication between
proper implementations"); so handshake_failure possibly is the best
choice, but this use doesn't quite match its description in the RFC
(according to the spec, it is about unacceptable "security
parameters", and that's a pretty specific term in the TLS
specification: see 6.1 and A.6).

This would be quite different if there was any error alert description
that said something along the lines of "This alert is sent if a
warning alert is received and this warning is treated as an error.
This message is always fatal."  (Maybe something like this should be
added to the handshake_failure description.)

Bodo

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jun 2007 16:53:41 +0200 (MEST)

>    [...]         if an alert with a level of warning is received, the

Where is the problem.  The receiver which treats a warning as a fatal
error is the "detecting" party:

                                                               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.

and therefore required to send a fatal alert before being allowed
to close the communication channel.

> warning alert, you may act as if you received a fatal alert".

No, this is wrong.

When receiving a warning alert, the receiving party may decide to handle
this to be a fatal error, resulting in a requirement to send a (fatal alert)
message to the other party.

The sender of the warning certainly didn't mean this to be a (fatal) error,
which is why it sent a warning and is waiting for a response/continuation
of the communication.

>
> Again, this is not what I *want* the specification to say or how I would
> like implementations to behave -- I just want the specification to say

I would also appreciate if the spec was more explicit about this,
and in particular I do *NOT* want this to be considered a change
to the existing spec that is new and valid only for TLSv1.2.

Documenting what a correct sender ought to do is fairly easy.
Documenting what behaviour receipients will have to deal with in
the wild is much harder, because of inconsistencies, defects and
silent backwards-incompatible changes in the history of the TLS spec.

> specification: see 6.1 and A.6).

The spec calls for a fatal handshake_failure alert in most situations.
Which, admittedly, isn't going to be very helpful for the peer. :-|

> added to the handshake_failure description.)

It seems strange that there are several alerts in SSL concerning certificate
validity/acceptance and even one to indicate that no (client) certificate
is available, but none for indicating certificate_required.

There was a warning alert added to TLSv1.0 in an IMHO broken fashion:
user_cancelled.  rfc2246 even suggest that this is followed up by
a close notify alert -- which I consider a serious mistake.

user_canelled should have been made an alternative "closure alert",
if any.

"close notify" only makes sense after a successfully completed SSL/TLS
handshake, it would be inappropriate during the SSL/TLS handshake.
for fully established SSL/TLS sessions.

"user_cancelled" was apparently added to perform a "graceful abort"
of a SSL/TLS handshake (probably with the intention that it does
not get logged or reported as a technical error).  As such, the
suggestion to followup with a close_notify is IMHO wrong.
close notify should only be used after a successful handshake.

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 12 Jun 2007 17:21:19 +0200

> to the existing spec that is new and valid only for TLSv1.2.

Not a change just for TLS 1.2, but a clarification for something that
previously was under-specified.

>> alert:      [...]
>>                           so handshake_failure possibly is the best

> The spec calls for a fatal handshake_failure alert in most situations.

One problem is that the spec doesn't really say that you can use
handshake_failure in such situations.  The spec can just as easily be
interpreted as saying that you can't.  (Common sense can come in
helpfully and say that you should use handshake_failure *despite of*
what the current spec says.)

Bodo

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Jun 2007 19:21:19 +0200 (MEST)

> previously was under-specified.

OK!

> what the current spec says.)

According to the SSL spec, a handshake failure alert is the appropriate
(server) response to a client sending a "no_certificate" warning alert
upon a Certificate Request message.

For every protocol you will need a catch-all error message that has
to be used whenever there is not specific error message available
to describe the situation (In GSS-API it is the MISC_FAILURE major_status)
In SSL, for errors during the handshake this is the handshake_failure alert.

What TLS currently doesn't provide is a means to communicate implementation
specific information about an error, which may be specific to particular
cipher-suites, specific to particular PKI operations (and not covered
by the existing certificate-related alerts), or eventually, specific
to alternative authentication protocols that people are trying to
add to TLS.  Maybe the alert protocol should be enhanced to provide
a container for such auxiliary error information before fancy new
authentication schemes are added to the TLS protocol engine.

-Martin