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

From: Trevor Perrin <[email-masked]>
Date: Thu, 24 Jan 2013 16:26:43 -0800

On Thu, Jan 24, 2013 at 4:10 AM, Emilia Kasper <[email-masked]> wrote:
> On Wed, Jan 23, 2013 at 8:25 PM, Trevor Perrin <[email-masked]> 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

---

From: Emilia Kasper <[email-masked]>
Date: Fri, 25 Jan 2013 17:55:18 +0100

> following the 1-byte type, but this is incorrect (see URLandHash in

Thanks, you're correct - we didn't get it quite right on first attempt.
We'll look into it.

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

I'm not sure I follow; do you mean specifying TLS extension data in a data
file? Surely that doesn't work for arbitrary extensions...

Emilia

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 25 Jan 2013 09:32:33 -0800

On Fri, Jan 25, 2013 at 8:55 AM, Emilia Kasper <[email-masked]> wrote:
> file?

Yes, I think you could do something much like the authorization data
file, except that the file would be a list of TLS Extension responses
instead of 5878 responses.

For any ClientHello extensions the server receives that have empty
extension_data, the server would look through this extension file and
add corresponding responses to its ServerHello.

> Surely that doesn't work for arbitrary extensions...

No, but it would work for simple TLS Extensions that are just stapling
some data into the handshake.  So, it would support things like CT's
SignedCertificateTimestamps, TACK, or other things (you mentioned a
"Revocation Transparency"; some sort of DNSSEC/DANE stapling; etc.)

Anyways, I think this would be a fantastically useful mechanism that
would ease the common burden of these various stapling proposals in a
simple, clean way.  If you're interested, I'd love to help with the
implementation...

Trevor

---

From: Ben Laurie <[email-masked]>
Date: Tue, 29 Jan 2013 14:00:45 +0000

> simple, clean way.  If you're interested, I'd love to help with the

I rather like this idea. Help welcome :-)