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

<Pasi.Eronen@nokia.com> Tue, 06 March 2007 12:40 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 1HOYyA-0002M4-WA; Tue, 06 Mar 2007 07:40:42 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOYy9-0002Ll-6S for tls@ietf.org; Tue, 06 Mar 2007 07:40:41 -0500
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOYy7-0003ML-Ko for tls@ietf.org; Tue, 06 Mar 2007 07:40:41 -0500
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l26CeV0L001151 for <tls@ietf.org>; Tue, 6 Mar 2007 14:40:35 +0200
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 14:40:25 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 14:40:25 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] sending error alerts: MUST? SHOULD? MAY?
Date: Tue, 06 Mar 2007 14:40:15 +0200
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2403DB556F@esebe105.NOE.Nokia.com>
In-Reply-To: <20070209224143.C1D075C01E@laser.networkresonance.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] sending error alerts: MUST? SHOULD? MAY?
Thread-Index: AcdMmunP/49aCCXEQv+kOELVPvpRrATUK3Lw
References: Your message of "Sun, 31 Dec 2006 15:13:24 PST."<45984414.2090209@bolyard.com> <20070209224143.C1D075C01E@laser.networkresonance.com>
From: Pasi.Eronen@nokia.com
To: tls@ietf.org
X-OriginalArrivalTime: 06 Mar 2007 12:40:25.0400 (UTC) FILETIME=[9CFB8B80:01C75FEC]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::070306144035-0334EBB0-4C1B5ED3/0-0/0-1
X-Nokia-AV: Clean
X-Spam-Score: 0.2 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
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>
Errors-To: tls-bounces@lists.ietf.org

Eric Rescorla wrote:
> 
> My concern, as I think I mentioned to you privately, is that we not
> mandate behaviors that potentially leak security relevant information.
> We've had one such situation before with CBC padding. Ultimately,
> we really need a review of the security implications of every kind
> of error, but not having that I'm reluctant to require behaviors
> that haven't been vetted.
> 
> The bottom line, then, is that I'd prefer not to change this language
> without explicit security analysis for each change.

(Replying to a somewhat old message...)

I think a general guideline would be that if you haven't used anything
secret yet (the RSA/DH/DSS private key, or any session keys), sending
an alert can't leak that secret. The problems we've had have all been
associated with revealing errors in processing involving a secret (RSA
errors, CBC padding, etc.).

So some of the alerts (e.g. those sent by server in response to
ClientHello) should be safe, and I do agree with earlier concerns
that the spec should be more clear about when they're used.

Best regards,
Pasi

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