On Thu, Jan 24, 2013 at 4:10 AM, Emilia Kasper <ekas...@google.com> wrote: > On Wed, Jan 23, 2013 at 8:25 PM, Trevor Perrin <tr...@trevp.net> 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 _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
