RE: [TLS] Expanding the alert space

"Linn, John" <jlinn@rsasecurity.com> Thu, 06 July 2006 12:45 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTEZ-0004W0-Fz; Thu, 06 Jul 2006 08:45:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTEY-0004Vv-V0 for tls@ietf.org; Thu, 06 Jul 2006 08:45:30 -0400
Received: from tholian.rsasecurity.com ([216.162.240.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyTEX-0005TX-LW for tls@ietf.org; Thu, 06 Jul 2006 08:45:30 -0400
Received: from hyperion.rsasecurity.com by tholian.rsasecurity.com via smtpd (for ietf-mx.ietf.org [156.154.16.150]) with ESMTP; Thu, 6 Jul 2006 08:44:26 -0400
Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by hyperion.na.rsa.net (MOS 3.7.4b-GA) with ESMTP id CPZ16027; Thu, 6 Jul 2006 08:49:00 +0500 (GMT-5)
Received: from rsana-ex-hq2.NA.RSA.NET (rsana-ex-hq2.na.rsa.net [10.100.8.51]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k66CjPDU020876; Thu, 6 Jul 2006 08:45:25 -0400 (EDT)
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: Thu, 6 Jul 2006 08:45:24 -0400
Message-ID: <CBF06F06E674C948AD89E671645B785F0103EDFD@rsana-ex-hq2.NA.RSA.NET>
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2402DDC688@esebe105.NOE.Nokia.com>
Thread-Topic: [TLS] Expanding the alert space
Thread-Index: AcagO2QxG+L4MXzPR96IKhMrS5MIxgABq/RQACv02zA=
From: "Linn, John" <jlinn@rsasecurity.com>
To: <Pasi.Eronen@nokia.com>, <ekr@networkresonance.com>, <tls@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
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

It's true that there are cases where more specific error reporting can
provide useful information for attackers.  I believe, though, that this
fact argues more for selective reporting in particular sensitive cases
than for an architectural constraint that limits definition and use of
alerts generally.  

Though relatively available for allocation today, an 8-bit flat space
seems small to describe a set of choices that continues to grow as new
methods are defined.  A 16-bit space would allow more flexibility.
Alternately, to reduce the extent to which the overall TLS-wide alert
set will need to expand in response to new methods, it could be useful
to allow a means to annotate a smaller number of top-level alerts with
more detailed status data that may be method-specific.  Eric's freeform
string suggestion is one possibility in this area. Another option might
be to introduce a subcode field, which would have registered values that
could be used (optionally) to provide more detailed status indications
in conjunction with a particular alert. 

--jl

-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] 
Sent: Wednesday, July 05, 2006 10:55 AM
To: ekr@networkresonance.com; tls@ietf.org
Subject: RE: [TLS] Expanding the alert space

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

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