RE: [TLS] Expanding the alert space

<Pasi.Eronen@nokia.com> Wed, 05 July 2006 17:20 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyB2o-0001xW-0P; Wed, 05 Jul 2006 13:20:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyB2k-0001uA-OF for tls@ietf.org; Wed, 05 Jul 2006 13:20:06 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8xi-0002nj-MP for tls@ietf.org; Wed, 05 Jul 2006 11:06:46 -0400
Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy8mJ-0002d4-9j for tls@ietf.org; Wed, 05 Jul 2006 10:54:59 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k65EsvDC029591; Wed, 5 Jul 2006 17:54:57 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 17:54:55 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 17:54:55 +0300
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] Expanding the alert space
Date: Wed, 5 Jul 2006 17:54:59 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402DDC688@esebe105.NOE.Nokia.com>
In-Reply-To: <20060705140425.B4687222425@laser.networkresonance.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Expanding the alert space
Thread-Index: AcagO2QxG+L4MXzPR96IKhMrS5MIxgABq/RQ
From: <Pasi.Eronen@nokia.com>
To: <ekr@networkresonance.com>, <tls@ietf.org>
X-OriginalArrivalTime: 05 Jul 2006 14:54:55.0174 (UTC) FILETIME=[FA265660:01C6A042]
X-Spam-Score: -1.8 (-)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
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:

> I've noticed lately that people seem to want to define a lot of new
> TLS alerts. What would people think about expanding the alert space
> in 1.2?  16 bits enough? I've considered a few times having a
> freeform string field as well that could be used to report errors in
> detail for debugging, but maybe that's too clever.
> 
> Thoughts?

Some statistics: in the 10+ years from SSL 3.0 to today, all approved
documents together have used a total of 30 alert numbers (of 256).
Currently active Internet-Drafts use 5.

So I don't think there's any immediate danger of running out of them.
And providing too detailed debugging information to the other party
is not necessarily a good idea (e.g. bad_record_mac/decryption_failed
and the CBC attacks resulting from it).

Best regards,
Pasi

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