Re: [TLS] RFC 5878 - why?

[Trevor Perrin <[e-mail]>]

On Tue, Sep 17, 2013 at 2:27 PM, Marsh Ray <[e-mail]> wrote:
>> From: Trevor Perrin [mailto:[e-mail]]
>> Sent: Tuesday, September 17, 2013 8:32 AM
>>
>> 5878 itself is quite ugly, and riddled with errors and design flaws.
>> Which is why I'm bringing this up.
>
> Now, now, be nice.

Did you see the errata?

 * It's a weird extension structure, instead of having the standard
2-byte type / 2-byte length fields, like TLS Extensions and 4680
SupplementalDataEntry, each AuthorizationDataEntry has a (too-small)
1-byte type field, and no length field.

 * Without the length fields it's not generically parseable (Ben
suggests fixing that in the errata, but that breaks compatibility with
the 5878 URLandHash structure).

 * The structure definitions in section 3 are wrong.

 * The submitted errata also argue that the length field for
authz_data_list should be removed.  While I agree its redundant,
that's another compatibility-breaking change, so I'm not sure about
that.

So I'm asking:  Is there a legitimate reason for the community to
spend time fixing this RFC, implementing it in TLS libraries (it's not
currently present in any libraries, I believe), and adapting new
standards to use it?

If not, can we mark it as "obsoleted" or similar?

Projects like TACK, CT, and OpenSSL have wasted a lot of time
evaluating 5878 and doing trial implementations before backing away
from it.  I worry that people (like DTCP) [1] are going to keep making
that mistake, as on the surface this seems like the
"officially-condoned", IETF way to exchange new data through TLS.


> Alternatively, if you know something exploitable please drop it while it's hot.
>
>> I don't know how you could "extend" it to a larger code space.  I suppose we
>> could nest another extension structure *inside* the 5878 structure, to see
>> how many parsing layers we can bury extensions inside...
>
> 254 authZ data formats ought to be enough for anyone. But if not, sure, we could indeed use 255 as a value to indicate a multi-byte value follows.

Don't we have some 65000+ unused TLS extensions?

If you really want a few hundred numbers for "Private Use" or
"Specification Required" extensions, why don't we just carve that out
of the existing TLS Extension space?


Trevor

[1] http://tools.ietf.org/html/draft-dthakore-tls-authz-04