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

[Emilia Kasper <[e-mail]>]

On Fri, Jan 25, 2013 at 1:26 AM, Trevor Perrin <[e-mail]> wrote:

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

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


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

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


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