Root SSL certificates and browser support

Nominally, in pure "X.509" philosophy, the SSL client should obtain the server's certificate and all needed intermediate CA certificates in any way it sees fit, but in particular by talking to the Directory, which is the giant worldwide LDAP server which contains everything.

Unfortunately, the Directory never existed (too centralized, too complex) so practical protocols have to include some provision for sending certificates themselves. It so happens in SSL/TLS: the server sends its own certificate and a bunch of other certificates which "may help" the client. In fact, the TLS standard even specifies that the server MUST send a ready-to-validate chain:

certificate_list
  This is a sequence (chain) of certificates.  The sender's
  certificate MUST come first in the list.  Each following
  certificate MUST directly certify the one preceding it.  Because
  certificate validation requires that root keys be distributed
  independently, the self-signed certificate that specifies the root
  certificate authority MAY be omitted from the chain, under the
  assumption that the remote end must already possess it in order to
  validate it in any case.

In particular, notice that the self-signed root itself may or may not be included. This root is never needed client side (and never has been) but sending it is "traditional" (one of the myriads of traditions in IT; not useful, but mostly harmless).

The client should be able to validate the certificate chain "as is" and is allowed (as in "morally justified"), per the TLS standard, to reject the handshake if the exact chain sent by the server cannot be validated. However, the client is also allowed (and encouraged) to try to rebuild some other chain and validate that, if what the server sent was not directly usable. Modern browsers do that; they will try to use locally known intermediate CA certificates (obtained at installation, or cached), and may also download extra CA certificates, following URL found in the certificates themselves (Authority Information Access extension). At least IE on (recent) Windows will do that, but, to avoid a nasty chicken-and-egg situation, it will follow only http:// URL, not https://. These extra downloads can take some time and make the handshake less robust, in case of flaky network or timeout.

Summary: sending the root is not mandatory, but traditional (the +1 kB network overhead per full handshake is unlikely to have any significant or even detectable impact on performance). Sending the intermediate CA is nominally required, and, in practice, recommended, although modern browsers/OS may recover by using alternate certificate chain building strategies.