Re: [TLS] RFC 5878 - why?

[Darshak Thakore <[e-mail]>]

I'm trying to understand if the primary issue being pointed out here is
about the errata in RFC5878 or the extension model that RFC5878 provides.
This thread started off with the primary question being what does RFC5878
provide and seems to be turning into a bashing of how bad it is. While i
agree that RFC5878 needs to be "fixed" in order to be usable, if we go
back to the original question of:

why this:

Client -> Server : ClientHello Extension signalling AuthorizationData
Client <- Server : ServerHello Extension signalling AuthorizationData,
                            SupplementalData containing AuthorizationData
Client -> Server : SupplementalData containing AuthorizationData

instead of this:

Client -> Server : ClientHello Extension
Client <- Server : ServerHello Extension
Client -> Server : SupplementalData (RFC 4680)


then:

1. You seem to be assuming that data is always flowing from the Client to
the Server and that anything that a server may want to send can always be
carried in the extension. That's not the only case. While it is possible
(and in most scenarios sufficient) to carry data in the extension itself,
certain extensions may require that actual data be passed in a specific
MessageType (based on certain aspects of the handshake being
accomplished). In such situations, the extension and the data in the
extension serves as triggers/extension code points to indicate what type
of data is to be expected in the subsequent messages. In order to achieve
that, if you do not define an extension code point, then your
extensionType registry starts exploding (with corner case extensions
littered around). While it is possible that way, IMHO, having a separate
code point and having a separate registry that provides a
categorization/registration of specific data types seems cleaner and
provides better management.

RFC4681 also does the same thing. It defines an extension and establishes
a registry to allow registering new UserMappings.

Going back to the problems of RFC5878 itself, the lack of length field
definitely needs to be fixed but the AuthorizationDataEntry being 1 byte
(while weird as you put it) is not really an issue.

Also as Yoav pointed out, due to lack of interest or whatever historic
reasons, there wasn't any other alternative/interest so RFC5878 was
published. When I actually had the need to pass DTCP data as authorization
data, RFC5878 provided the closest option (for better or for worse).

 
So my (very biased :) counter question is if RFC5878 is fixable, why not
fix it and leverage the registry already defined. If it is obsoleted,
wouldn't an alternative still be needed?


Darshak



On 9/17/13 6:37 PM, "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.
>
>
>> 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
>_______________________________________________
>TLS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls