Re: [TLS] RFC 5878 - why?

[Yoav Nir <[e-mail]>]

On Sep 18, 2013, at 3:37 AM, Trevor Perrin <[e-mail]> wrote:

> 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.

RFC 5878 is an experimental RFC. If you've looked at its history, it was approved by the IESG in 2006, and an IPR issue surfaced, so approval was withdrawn, and the draft lay dormant for 3 years. If during those three years anyone had come up with some other draft describing an authorization extension, I think that would have been approved instead. But nobody did. 

I took that to mean that there was very little interest in passing authorization information in the TLS handshake. So after three years, the IESG agreed to publish it anyway, and as the errata show, it received very little review.

In any case, it's an experimental RFC and if the DTCP want to send information (whether authorization-related or not) in an extension, they can use it or not use it as they see fit.

Yoav