Advanced SSL Topics - Implementing SSL/TLS Using Cryptography and PKI - page 465

Step-up Cryptography
There are yet more restrictions on export-grade ciphers. If RSA is used for
key exchange, the modulus can be no larger than 512 bits. Of course, the same
restrictions were put on DH key agreement; the exchanged parameters — Yc
and Ys — could not be longer than 512 bits.
However, implementations were actually allowed to present certifi cates with
public keys whose moduli were longer than 512 bits; they just couldn't use
those for key exchange. So, you may ask, how was key exchange performed
in this case? Actually, if the selected cipher was an exportable one, the certifi -
cate could contain an arbitrarily sized public key, but the server was required
to turn around and send an ephemeral RSA key in a server key exchange
message! Recall that the server key exchange message permitted the ephem-
eral key to be signed by the public key in the certifi cate. So, in this case, the
long key signed the short key. In fact, it is entirely permissible for the certifi cate
to contain a DSS key that signs a shorter ephemeral RSA key. This scenario
was referred to as server gated or step up cryptography. You might still come
across the term from time to time in older documentation, but be aware that
the U.S. government has relaxed its export restrictions and no commercial CA
sells server gated certifi cates anymore.
In theory, this approach could also be used in modern TLS to permit RSA
key exchange to achieve perfect forward secrecy as does Diffi e-Hellman. A
certifi cate with a fi xed RSA key could be presented, followed by a server key
exchange message with a (strong) ephemeral RSA key. However, the TLS 1.0
specifi cation states that the server key exchange message “is sent by the server
only when the server certifi cate message (if sent) does not contain enough data
to allow the client to exchange a premaster secret.” In other words, sending
a server key exchange message when the selected cipher suite is neither an
ephemeral Diffi e-Hellman key exchange method nor an exportable RSA key
exchange is an error. Internet Explorer actually accepts such an out-of-place
server key exchange message, although Firefox and Chrome (correctly, per the
spec) reject it as invalid.
Discarding Key Material Through Session
Renegotiation
In some ways, session renegotiation is the opposite of session resumption.
Session resumption exists to allow a client to reuse previously negotiated
keying material so that the negotiated keys don't “go to waste.” Session rene-
gotiation, on the other hand, is a way for either side to indicate that it believes
that the keying material has been used plenty, thanks, so it's time to establish
some new ones.