Implementer's notes

For some time now Opera has supported the Certificate Status Request Extension to TLS, although we did have a false start which was fixed in Opera 9.26.

What this extention does is to provide a way for a client to ask the server to do the OCSP revocation check for its own certificate, rather than the client doing a separate connection to the issuer's OCSP responder. The benefit of this policy is that the client saves time completing the connection since it does not have to wait for the OCSP responder. Also, if the server stores the OCSP response for a while, then the traffic to the OCSP responder becomes much lower (and much less expensive). Mostly servers will request updates and not all the clients visiting the site. This is called TLS OCSP stapling.

This mechanism only works for the server's own certificate. It does not work for any of the other certificates in the chain, and these days most Certificate Authorities (CAs) use at least one intermediate certificate, and some use four, or more. Today all the revocation information about these are retrieved using CRLs, not OCSP. This means that the information is not as up-to-date as is possible for OCSP, as CRLs (particularly for intermediates) are valid for much longer periods than OCSP. This may not be an issue today because most intermediates are controlled by the CA or other relatively big CAs, but it could become a problem if CAs start issuing large numbers of intermediate CA certificates that they do not control, for example to corporate customers. This might become a possibility if/when better domain limitations are widely implementated in browsers. If one of those corporate customers or an independent sub-CA starts issuing bad certificates, it is imperative to be able to revoke those CA certifiates quickly, which would be difficult if the CRL was updated every 12 months. On the other hand, OCSP responses are usually valid for less than a week.

Some intermediate CA certificates are now issued with OCSP URLs specified, but no browsers are currently using them. It is my recommendation that they do not start using them. The reason is that for all clients to use OCSP to check intermediate CA certificates would increase traffic to those
servers multifold, perhaps dozens of times when TLS OCSP Stapling becomes widespread, meaning the bandwidth cost for the CA will increase significantly. A number of CAs have already been concerned about the cost of supporting OCSP just for server certificates while waiting for stapling to become widespread; they would not like the cost of supporting OCSP for one or more intermediate certificates.

The solution, of course, is to expand the TLS Extension to support multiple OCSP responses, which should have been a fairly straightforward task, which it was for the handling of the responses. It turned out, however, that it was not practical to use the existing Certificate Status Request extension in TLS, since it does not allow multiple methods to be specified (but only a single method), which would be necessary to support servers that do not support the new response format. The limitation is due to both a hard restriction in TLS, as only one entry for a given extension can be sent in any extension list, and the request extension only permits a single format to be specified, not multiple.

The solution in the end was to create a new extension that permits multiple formats to be specified, not just a single one as before.

I have just submitted an Internet Draft to the IETF TLS Working Group defining such an extension and new response format. The draft is based on the existing definition with enhancements for the new requirements.

I hope the TLS WG will take on the work to help me complete the draft so that we can get this new functionality into all new clients and servers as soon as possible.

Comments intended as contributions to the draft should also be posted at the TLS WG mailing list.

draft-pettersen-tls-ext-multiple-ocsp-00.txt (archive)

If there is one unchanging thing about computing and the Internet, it is ... change. That is why well engineered protocols and devices are designed to allow newer, improved versions of the protocol or device to be invented. Such flexibility permits them to interact with both older and newer implementations of the protocol or device, so that not everyone need change to the newest version at the same time.

As an example: The reason you will soon "have" to buy a new, more advanced DVD- player in order to play the new DVDs is because the old DVD players does not recognize the new format and the new discs are using a format and data storage method that cannot be read by the old ones. IOW: while there may be insurmountable technical difficulties causing it, DVD players are not forward compatible, and the new DVD formats are not backward compatible.

Many Internet standards, HTML, HTTP, SSL/TLS are both forward and backward compatible. Or rather: They are supposed to be. Actual performance varies between implementations.

Over the past seven years I have been phasing in several new versions and enhancements to the SSL and TLS protocol. Versions and enhancements that were supposed to work with implementations of the older versions without any problem.

They didn't.

The SSL and TLS specifications (all four of them) specify that a client supporting the newer version can connect to a server that only supports some of the older versions, and how they negotiate the version (client tells the server its highest version, and the server picks the lowest version of what the server supports and what the client supports).

Except for the first version (SSL v2), all SSL and TLS versions are binary compatible, and the negotiation formats are also permitted to change, in particular the two first messages. The specification clearly specifies that those two messages can contain more data than was defined at the time the specification was written. With TLS Extensions, those new data fields were defined.

However, not everyone implemented these features as well as they should.

As mentioned in my Opera Labs article (and also here), some older SSL v3 servers refused to talk to TLS 1.0 clients, or when they would talk they used the wrong information internally, causing a connection failure. History repeated itself when TLS 1.1 was introduced.

Also, TLS 1.0 servers refused to accept TLS Extensions, even though they are supposed to ignore what they do not support.

Additionally, there may be a problem with the backward compatibility requirements. I've either misunderstood that section for most of the past nine years, or it isn't clear enough about what it means. What I discovered was that for some SSL v3 and TLS servers which protocol versions and how they were signaled during the handshake was a bit too important, and in some cases servers used the wrong protocol version field when negotiating.

Frankly, it's starting to look messy.

While it does not affect most servers, the problem is that many of these problems occur on important sites such as online banking sites, which means that unless you can compensate for the problems, you have to wait until the sites fix their servers. An alternative approach is to tell the sites to fix their servers, or the customers won't be able to access them, which is effectively what Microsoft did when they implemented TLS Extensions in Vista, where TLS Extensions cannot be disabled. But they may be big enough to make it stick.

In order to compensate for all of this, and more, Opera's SSL/TLS stack had to get a whole lot of logic that could compensate for all of the problems. This permitted us to enable TLS 1.1 and TLS Extensions.

At the last IETF meeting, IETF-65 in Dallas, I was invited to make a short presentation of my experiences. After the presentation I was asked to write a more extensive report about what I had observed.

The first draft of this report is now available as an Internet Draft

Why is it important to be aware of this?

One answer is that knowing what has gone wrong, we can work to improve the process so that we can avoid the problem in the future. My draft does not try to solve the problems, but does ask if certain changes to the process might help.

Another answer is that the countermeasures that several clients have implemented actually negates security features in parts of the protocol. In particular, the version roll-back protection for the RSA cipher suites is affected by this problem. This feature is supposed to prevent an attack that leverages a (potentially) weaker version of the protocol. It is, however, not possible to tell an incorrectly implemented server from a malicious attack.

A third answer is that work is now getting underway to define TLS 1.2. This version is going to introduce new protocol integrity methods, which are what is used to ensure that the protocol data have not been tampered with, because the old methods are starting to show weaknesses.

If it becomes difficult to introduce a new version of the protocol, in particular one intended to increase security, and the only fallback the clients have is to disable the new protocol version (thus creating a security vulnerability) as a part of their normal operating procedure in order to connect to older servers, then we have a very serious problem on our hands.

The good thing is that we are nowhere close to such a situation. Yet.

The only way to handle it, is to forbid clients to disable version in the manner it is currently done. This would enable clients to negotiate safely, but it might cause important services to fail.

Which means we have a problem no matter which choice we make.