Adding TLS 1.2 Support to Your TLS Library - Implementing SSL/TLS Using Cryptography and PKI - page 489

read_pos = read_buffer( ( void * )
&request.supported_signature_algorithms[ i ].signature, read_pos, 1 );
}

read_pos = read_buffer( ( void * ) &trusted_roots_length, read_pos, 2 );

The supported signature/hash algorithms list occurs between the list of sup-
ported certifi cate types and the list of trusted root authorities. The length of the
list is declared as being two bytes, even though there are only 7 4 = 28 possible

combinations of signature and hash algorithms; the length is declared to be this
long for future extensibility. In a full-featured implementation, the signature and
hash algorithms are used to select an appropriate certifi cate, end the handshake
prematurely, or just decline to supply a certifi cate and see what happens.
Now, it may occur to you that it's not very fair for the server to list its sup-
ported signature and hash algorithms while the client is left at the mercy of
whatever the server supports, and you'd be right. RFC 5246 also standardizes a
new client hello extension that enables the client to list its supported signature
and hash algorithms; this extension takes the same form as the list of signa-
ture and hash algorithms in the certifi cate request (see Listing 8-29). This new
extension is extension number 13 and is documented in section 7.4.1.4.1 of the
TLS 1.2 specifi cation.
To summarize, TLS 1.2 differs from TLS 1.0, at the message-format level, in
the following ways:

Initialization vectors are explicitly declared at the start of each message
for block ciphers.
The client can negotiate, by way of a new hello extension, a stronger hash
algorithm to be used whenever the algorithm itself calls for one.
The PRF is based on a single hash, rather than a combination of MD-5 and
SHA-1. If no stronger hash algorithm is negotiated, the default is SHA-256.
The fi nished message's verify data is also based on SHA-256 instead of
MD-5 and SHA-1.
Signatures computed over handshake messages such as the server key
exchange and certifi cate verify declare their hash and signature algorithms
explicitly.

The changes described in this section are, at a minimum, what you need to
change in order to support TLS 1.2. Of course, there's no signifi cant benefi t
to making these changes just to upgrade to TLS 1.2 if you don't take advantage
of the cool new features that it includes. The following two sections examine the
most signifi cant cryptographic advances introduced by TLS 1.2: Authenticated
Encryption with Associated Data (AEAD) ciphers and Elliptic-Curve Cryptography
(ECC) support.