Re: [TLS] Issue 16: Alert clarifications

Eric Rescorla <ekr@networkresonance.com> Sat, 07 July 2007 23:46 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7JzI-0004Yx-96; Sat, 07 Jul 2007 19:46:52 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7JzH-0004Yr-5L for tls@ietf.org; Sat, 07 Jul 2007 19:46:51 -0400
Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7Jz1-0007RZ-TE for tls@ietf.org; Sat, 07 Jul 2007 19:46:51 -0400
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 408E033C1A; Sat, 7 Jul 2007 16:43:58 -0700 (PDT)
Date: Sat, 07 Jul 2007 16:43:57 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Nelson B Bolyard <nelson@bolyard.com>
Subject: Re: [TLS] Issue 16: Alert clarifications
In-Reply-To: <466CB8EF.9080700@bolyard.com>
References: <20070603145730.4507B33C4B@delta.rtfm.com> <B356D8F434D20B40A8CEDAEC305A1F2404395329@esebe105.NOE.Nokia.com> <20070607132918.4459D33C58@delta.rtfm.com> <4668CDF7.9030600@bolyard.com> <20070608083514.GA11066@tau.invalid> <466CB8EF.9080700@bolyard.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20070707234358.408E033C1A@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
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

At Sun, 10 Jun 2007 19:52:31 -0700,
Nelson B Bolyard wrote:
> > Why not require that a fatal alert be sent any time that the connection
> > is going to be torn down due to a protocol error of any kind?
> 
> I still think that deserves an answer.

As I said previously, I'm not comfortable with this without a full
security analysis of all of the implications of every single thing
that might go wrong, esp. as we have been burned by inappropriate
alerts in the past.

Since nobody has volunteered to do said analysis, the minimum
safe thing is to simply require that the current fatal alerts
be sent. I appreciate that you feel that it would make debugging
easier to require an alert in every case, but, then, so would
including the exact line of code on the local side that generated
the failure, but I don't hear anyone proposing that, so I don't
think this is the only consideration.

-Ekr



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