Re: [TLS] RFC 5878 - why?

[Trevor Perrin <[e-mail]>]

On Mon, Sep 16, 2013 at 11:53 PM, Marsh Ray <[e-mail]> wrote:
>> Trevor Perrin
>> Sent: Monday, September 16, 2013 9:16 PM
>> Subject: [TLS] RFC 5878 - why?
>>
>> Hi,
>>
>> Does anyone know of a reason to use RFC 5878?  Extension data can already
>> be sent in TLS handshakes:
>>
>> Seems like a bunch of added parsing for nothing?  What is this for?
>
> One useful thing it does is acquires an extension code point from IANA as well as defines a few values for specific types of authZ data.

But those specific types (or any others) could just have been defined
as TLS Extensions.  (Does anyone actually use SAML in TLS??  or X.509
Authorization certs?).

Also, note 5878 only has an 8-bit space for "authZ types", which seems
*much worse* than just using 16-bit TLS extension numbers in terms of
number exhaustion or risk of collision.


> But probably the bigger reason is that some percentage of TLS servers in the wild will crash or (worse) hang when they receive a Client Hello with too much data. Nobody is really sure how much data is safe to send in the Client Hello, so getting preapproved with a small extension is safest.

OK, but see my first diagram:
 - The server can send whatever it wants as a ServerHello extension
 - The client can send whatever it wants in response as RFC 4680
SupplementalData

So that problem is easily avoided without 5878.

Still not seeing the point...


Trevor