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

"Whyte, William" <WWhyte@ntru.com> Tue, 02 January 2007 11:27 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hnv-0004pd-US; Tue, 02 Jan 2007 06:27:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1hnu-0004n1-1E for tls@ietf.org; Tue, 02 Jan 2007 06:27:38 -0500
Received: from webmail.ntru.com ([64.115.150.147] helo=OHTHREE.jjj-i.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1hnr-0006CR-9y for tls@ietf.org; Tue, 02 Jan 2007 06:27:38 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [TLS] sending error alerts: MUST? SHOULD? MAY?
Date: Tue, 02 Jan 2007 06:25:16 -0500
Message-ID: <9DC3EBEFB87A97498A7D25F130DE27E4054255@ohthree.jjj-i.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] sending error alerts: MUST? SHOULD? MAY?
Thread-Index: AcctMTeGpoxumXNNQkiXGDPkpgkGrQBKxeHBAAEXq88=
References: <44D32FC2.2080606@bolyard.com> <45984414.2090209@bolyard.com> <9DC3EBEFB87A97498A7D25F130DE27E4054253@ohthree.jjj-i.com>
From: "Whyte, William" <WWhyte@ntru.com>
To: "Whyte, William" <WWhyte@ntru.com>, Nelson B Bolyard <nelson@bolyard.com>, tls@ietf.org
X-Spam-Score: 0.1 (/)
X-Scan-Signature: da41e01217ab11ad82db577473e913ae
Cc:
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>
Content-Type: multipart/mixed; boundary="===============0849266459=="
Errors-To: tls-bounces@lists.ietf.org

It turns out to be something to do with the Skype toolbar trying to convert
Nelson's
 
12345678901234567890123456789012345678901234567890123456789012345678901234567890
00000000011111111112222222222333333333344444444445555555555666666666677777777778

into a phone number. (I got similar behavior when I looked at Nelson's 
mail on the web archives http://www1.ietf.org/mail-archive/web/tls/current/msg01286.html
in Firefox, where I also have the Skype toolbar installed). Nice one, Skype!
 
William

________________________________

From: Whyte, William [mailto:WWhyte@ntru.com]
Sent: Tue 1/2/2007 5:54 AM
To: Nelson B Bolyard; tls@ietf.org
Subject: RE: [TLS] sending error alerts: MUST? SHOULD? MAY?


When I open this mail, or any of the replies to it, in Outlook:
* Outlook goes up to taking up 95% of my CPU time
* Outlook's memory requirements go up from 50(ish) MB to 190(ish)
* Outlook, unsurprisingly, becomes unresponsive and has to be shut
  down from the Task Manager.
 
Is anyone else experiencing this?
 
William

________________________________

From: Nelson B Bolyard [mailto:nelson@bolyard.com]
Sent: Sun 12/31/2006 6:13 PM
To: tls@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 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