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 email@example.com; Tue, 02 Jan 2007 06:27:38 -0500
Received: from webmail.ntru.com ([184.108.40.206] helo=OHTHREE.jjj-i.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1hnr-0006CR-9y for firstname.lastname@example.org; Tue, 02 Jan 2007 06:27:38 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [TLS] sending error alerts: MUST? SHOULD? MAY?
Date: Tue, 2 Jan 2007 06:25:16 -0500
Thread-Topic: [TLS] sending error alerts: MUST? SHOULD? MAY?
References: <44D32FC2.email@example.com> <firstname.lastname@example.org> <9DC3EBEFB87A97498A7D25F130DE27E4054253@ohthree.jjj-i.com>
From: "Whyte, William" <WWhyte@ntru.com>
To: "Whyte, William" <WWhyte@ntru.com>, "Nelson B Bolyard" <email@example.com>, <firstname.lastname@example.org>
X-Spam-Score: 0.1 (/)
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:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:firstname.lastname@example.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0849266459=="
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; email@example.com 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:firstname.lastname@example.org] Sent: Sun 12/31/2006 6:13 PM To: email@example.com 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 220.127.116.11 says: "it will respond with a handshake failure alert." > no MUST there. > > I found two MUSTS in 18.104.22.168.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
- [TLS] sending error alerts: MUST? SHOULD? MAY? Nelson B Bolyard
- Re: [TLS] sending error alerts: MUST? SHOULD? MAY? Nelson B Bolyard
- Re: [TLS] sending error alerts: MUST? SHOULD? MAY? Ben Laurie
- Re: [TLS] sending error alerts: MUST? SHOULD? MAY? Kyle Hamilton
- RE: [TLS] sending error alerts: MUST? SHOULD? MAY? Whyte, William
- RE: [TLS] sending error alerts: MUST? SHOULD? MAY? Whyte, William
- Re: [TLS] sending error alerts: MUST? SHOULD? MAY? Eric Rescorla
- RE: [TLS] sending error alerts: MUST? SHOULD? MAY? Pasi.Eronen