[therightkey] CT and RFC 5878 (was Re: CT Qs)

[Trevor Perrin <[e-mail]>]

On Thu, Jan 24, 2013 at 4:10 AM, Emilia Kasper <[e-mail]> wrote:
> On Wed, Jan 23, 2013 at 8:25 PM, Trevor Perrin <[e-mail]> wrote:
>>
>> Defining your own TLS Extension seems simpler, why not do it from the
>> start?


To expand on this:  RFC 5878 seems unnecessary for server-provided
data such as CT's SignedCertificateTimestamps (or similar things like
TACK [1]).

TLS already has an extension mechanism.  5878 uses this extension
mechanism to add a new extension mechanism.  But the new mechanism
seems pointlessly redundant, complex, and not widely implemented.
It's also poorly designed and specified:

 * 5878 builds on the SupplementalData TLS handshake message defined
in 4680.  But 5878's extension of 4680 appears wrong:  The
"SupplementalData" structure in 5878 does not match the same-named
structure in 4680.  I think 5878 is trying to extend 4680's
SupplementalDataEntry, but it's still wrong (missing
supp_data_length).

 * 5878's AuthorizationDataEntry has no overall length field, thus is
not generically parseable (it can only be handled by a parser which
knows the structure corresponding to each authz_format it encounters).
 The OpenSSL implementation [2] attempts to parse it by assuming every
AuthorizationDataEntry contains a 2-byte overall length field
following the 1-byte type, but this is incorrect (see URLandHash in
5878).

The claim is:

> We've already implemented 5878 for OpenSSL and Apache. The wider benefit of
> a more general mechanism is that adding new types of authorization data
> (Revocation Transparency?) will in the future not require upgrading servers
> again.

But this isn't an inherent virtue of 5878, it's due to the CT team
adding functionality to OpenSSL and Apache that allows specifying
server responses in a data file [3].  The server can parse the data
file and return whichever responses the client asks for, without
needing code changes to know their meaning.

That's a great mechanism, but why not apply it to TLS Extensions?
Then we could deploy CT's timestamps (or other server auth data)
without needing server code changes *or* 5878.

That would be the best of both worlds, wouldn't it?


Trevor


[1] http://tools.ietf.org/html/draft-perrin-tls-tack

[2] For OpenSSL, see ssl_rsa.c:authz_validate(), and incorrect comment
in ssl_locl.h:

	/* authz/authz_length contain authz data for this certificate. The data
	 * is in wire format, specifically it's a series of records like:
	 *   uint8_t authz_type;  // (RFC 5878, AuthzDataFormat)
	 *   uint16_t length;
	 *   uint8_t data[length]; */

[3] OpenSSL's SSL_CTX_use_authz_file(), Apache's SSLRSAAuthzFile directive