Re: [TLS] RFC 5878 - why?

[Trevor Perrin <[e-mail]>]

On Tue, Sep 17, 2013 at 10:04 PM, Darshak Thakore
<[e-mail]> wrote:
> 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.

My primary question is what value (if any) 5878 provides.


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

I don't see your point.

A TLS ServerHello Extension can carry ~64 KB, same as the 5878
AuthorizationDataEntry.

If that's not sufficient and you need to modify the TLS Handshake
somehow based on signalling in the ClientHello and ServerHello, I
still don't see how 5878 makes any difference.


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

You're worried about excess consumption of code points?  Switching
from a 16-bit space to an 8-bit space *exacerbates* that problem, it
doesn't solve it.


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

The alternative is to pass data via the standards-track mechanisms of
Hello Extensions and RFC 4680

Trevor