Subject: [TLS] Expanding the alert space

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Jul 2006 06:56:16 -0700

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?
-Ekr

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Wed, 5 Jul 2006 17:54:59 +0300

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

---

From: "Linn, John" <[email-masked]>
Date: Thu, 6 Jul 2006 08:45:24 -0400

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: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 05, 2006 10:55 AM
To: [email-masked]; [email-masked]
Subject: RE: [TLS] Expanding the alert space

Best regards,
Pasi

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 6 Jul 2006 15:20:45 +0200

On Wed 05 Jul 2006 15:56, Eric Rescorla wrote:
> 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.

I am scared of a freeform string, because in the end it would
need to handle internationalization (because somebody will think it's 
usefull information to print to the user) etc etc... thus we might
later need a TLS extension to specify the language, encodings and so on.
It might be too much for such a protocol!

About the extension to 16bit... I'm not totally against, but unless TLS 
1.2 is significantly different[0] than 1.1, I wouldn't go for it.

[0]. In the sense that if there too many incompatible changes, one more 
doesn't harm :)

regards,
Nikos