On Fri, Jan 25, 2013 at 1:26 AM, Trevor Perrin <[email protected]> wrote:
> On Thu, Jan 24, 2013 at 4:10 AM, Emilia Kasper <[email protected]> wrote: > > On Wed, Jan 23, 2013 at 8:25 PM, Trevor Perrin <[email protected]> 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 >
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
