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

["Ben Laurie" <[e-mail]>]

On 12/31/06, Nelson B Bolyard <[e-mail]> wrote:
> 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?

If you're going to make errors MUSTs you need to do so carefully,
since information leakage through alerts has been the basis of several
attacks on SSL/TLS.

> 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 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
> 12345678901234567890123456789012345678901234567890123456789012345678901234567890
> 00000000011111111112222222222333333333344444444445555555555666666666677777777778
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tls
>

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