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

"Kyle Hamilton" <aerowolf@gmail.com> Mon, 01 January 2007 13:57 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1NfG-00013f-Qn; Mon, 01 Jan 2007 08:57:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1NfF-00010R-66 for tls@ietf.org; Mon, 01 Jan 2007 08:57:21 -0500
Received: from wx-out-0506.google.com ([66.249.82.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1NfE-0000q4-RK for tls@ietf.org; Mon, 01 Jan 2007 08:57:21 -0500
Received: by wx-out-0506.google.com with SMTP id h27so5669492wxd for <tls@ietf.org>; Mon, 01 Jan 2007 05:57:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QJj8s42u0fm962T14VGaRoZ0FF2o9+Un7gMcaM3A1WbLwPWs98LM8w0r1+R95SjijPqZ7cuYKWyynn8mrmTHtemFQNzjdFMhOsGEGr1wqNE0od4SgBfnsoLxAPN+2KJKFxCkTn5cryXmNB9qqkgUNS72I//vM49Ihk/SeVkrWUI=
Received: by 10.90.105.20 with SMTP id d20mr13663290agc.1167659840652; Mon, 01 Jan 2007 05:57:20 -0800 (PST)
Received: by 10.90.56.2 with HTTP; Mon, 1 Jan 2007 05:57:20 -0800 (PST)
Message-ID: <6b9359640701010557n37258268p7a5d6cbe087de98e@mail.gmail.com>
Date: Mon, 1 Jan 2007 06:57:20 -0700
From: "Kyle Hamilton" <aerowolf@gmail.com>
To: "Ben Laurie" <benl@google.com>
Subject: Re: [TLS] sending error alerts: MUST? SHOULD? MAY?
In-Reply-To: <1b587cab0701010307r32b56732nf85f545848a449a8@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <44D32FC2.2080606@bolyard.com> <45984414.2090209@bolyard.com> <1b587cab0701010307r32b56732nf85f545848a449a8@mail.gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

I think that probably the only "MUST" that should be in place is "if
there is an error, a fatal error MUST be sent".  I'd also go so far as
to suggest that "protocol_error" be the generic one that must be sent
if the implementation wishes not to leak any information at all.  (the
remote is an untrusted entity in the grand scheme of things... I
wouldn't listen if it said I was speaking improperly anyway.)

-Kyle H

On 1/1/07, Ben Laurie <benl@google.com>; wrote:
> On 12/31/06, Nelson B Bolyard <nelson@bolyard.com>; 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
> > TLS@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/tls
> >
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
>


-- 

-Kyle H

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