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, 06 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
- [TLS] Expanding the alert space Eric Rescorla
- RE: [TLS] Expanding the alert space Pasi.Eronen
- RE: [TLS] Expanding the alert space Linn, John
- Re: [TLS] Expanding the alert space Nikos Mavrogiannopoulos