RE: sending error alerts: MUST? SHOULD? MAY?
2007-01-02 10:54:00 GMT
From: Nelson B Bolyard [mailto:nelson <at> bolyard.com]
Sent: Sun 12/31/2006 6:13 PM
To: tls <at> ietf.org
Subject: Re: [TLS] sending error alerts: MUST? SHOULD? MAY?
Last August, I wrote to this list about the lack of "MUST" in
the RFCs and
drafts concerning the use of error and warning alerts. That message is
quoted below. I only got one reply, from Peter Gutmann.
I really want to see this situation get fixed in TLS 1.2. What can I do
to make that happen? Do I need to submit a draft with the suggested changes?
Erik, if I send you a set of suggested changes as edits to the current 1.2
draft, will you incorporate them?
OBTW, the "newer implementation" that nevre sends error alerts has been
released since I wrote that first message. Can you guess what it is?
Nelson B Bolyard wrote:
> 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 18.104.22.168 says: "it will respond with a handshake failure alert."
> no MUST there.
> I found two MUSTS in 22.214.171.124.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.
TLS mailing list
TLS <at> lists.ietf.org
_______________________________________________ TLS mailing list TLS <at> lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls