- From: Brian Smith <bsmith@mozilla.com>
- Date: Fri, 25 Nov 2011 09:41:46 -0800 (PST)
- To: Mitch Zollinger <mzollinger@netflix.com>
- Cc: public-identity@w3.org
Mitch Zollinger wrote: > We've been using our own lightweight security wrapper for our own > protocol for 4 years now. It's been working really well. We use tokens > containing session keys (HMAC & encryption keys) encrypted with a > symmetric key known only to the server (a little like Kerberos) so > each transaction requires a single round trip and two messages (a > request & response) unlike the two round trips & 9 messages sent > for a regular (no client auth) SSL handshake just to open the socket > before I send a single byte of application data over HTTP(S) or > otherwise. I think we need to clarify which problems are (1) inherent TLS protocol problems that are difficult to solve, (2) TLS protocol issues that could be fixed with small incremental enhancements, (3) and which problems are caused by poor implementations of the protocol that can/will be solved by improving those implementations. Examples: (1) Certificate validation issues like prevention of mis-issuance, clock management issues. (2) Lack of intermediate CA OCSP stapling, lack of reliable indication that TLS False Start will work, poor ordering of TLS handshake messages (3) Lack of EE OCSP stapling, lack of TLS session ticket support, lack of TLS False Start support, inefficient certificate validation. Note that issues in category #3 affect browsers, server software makers, server hardware makers, and cloud service providers, and all of us would have to make improvements. But, I think these quality-of-implementation issues are being solved quite rapidly now that more websites are using HTTPS for nearly everything. - Brian
Received on Friday, 25 November 2011 17:42:14 UTC