[TLS] sending error alerts: MUST? SHOULD? MAY?

The existing TLS RFCs and IDs don't say that an implementation MUST send
any error alerts.

There's lots of "will", "should", "may", but not nearly enough "MUST"
(IMO) regarding error alerts (whether fatal or not).

Consequently, one of the newer implementations (which I won't name here),
one with which I've been doing interoperability testing, simply NEVER sends
error alerts.  When any problem occurs, it silently closes the connection
without offering any clues to the peer about why it has done so.  The
developer's explanation to me for the implementation's behavior was simple:
the RFCs do not require that error alerts be sent.  Sending error alerts is
simply not a MUST.  Doing so is implicitly a MAY, at most.

I think this is going to be a nightmare for trouble shooting.  When a peer
system drops a TLS connection, we're going to have to rely on the ability
of the user or administrator who runs that peer to determine why it did so,
rather than relying on alerts.

So, I put the question to the TLS WG:  Is there consensus that the RFC
language should be strengthened in the next version (e.g. rfc4346-bis)
to say that the error alerts MUST be sent, and when?

A survey of error alert discussion in the first 40-some pages of the draft.

Regarding close notify alerts, the existing RFC and drafts say that "each
party is required to" (why not MUST?) send a close_notify alert if no error
condition has occurred and that upon receiving a close-notify alert, the
peer MUST send one in respnse.  So, close_notify alerts will get sent,
but not error alerts.

The latest draft says that when an error alert is sent or received, the
session MUST be invalidated, but doesn't require that it be sent.

The draft says:
   "When an error is detected, the detecting party sends a
    message to the other party."
I think that should be MUST SEND, but as written it's not a MUST.

There are some "SHOULD"s in the current draft rfc4346-bis:
   "The receiver MUST check this padding and SHOULD use the
    bad_record_mac alert to indicate padding errors."

I think this was intended to be understood as "MUST check, MUST send an
alert to indicate errors, and SHOULD use bad_record_mac alert when
appropriate".  But as written, it clearly makes sending any alert at all
at most a SHOULD for bad macs.

no_renegotiation is a should, (and a MUST NOT) but never a SHOULD nor a
MUST.  certificate_unobtainable is a MAY.

The text for client_hello says
   "The server will select a cipher suite or, if no acceptable choices are
    presented, return a handshake failure alert and close the connection."
No MUST in there.

The alerts on page 30 MUST NOT be sent except when the client used a
hello extension.  But there is no time when they MUST be used.

In the current draft, I did find a few MUSTs.

Page 37 has an inferred "will":
   The server will select a cipher suite or, if no acceptable choices are
   presented, return a handshake failure alert and close the connection.

page 39 has a MUST:
   "... if not then it MUST send a fatal "decode_error" alert."

section 7.4.1.3 says: "it will respond with a handshake failure alert."
    no MUST there.

I found two MUSTS in 7.4.1.4.2 on page 44.  Also a SHALL (isn't that
supposed to be a MUST?)

I'll stop there without reviewing every weak description of an error alert.
Let's please have more MUSTs.

-- 
Nelson B

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