Auxilliary material for TLS 1.2 - TLS Parameters - Registries

After understanding the TLS handshake, there are still many moving parts that
have still not been satisfactorily explained. Perhaps the most important in
those is the assignment of the byte values for each of the cipher suites,
handshake message numbers, etc to the different things that have predefined
lists.

These are defined in the TLS
Parameters
document, maintained by the Internet Assigned Numbers Authority (IANA). If you
didn’t already know, the IANA is also responsible for allocating Autonomous
Systems on the Internet backbone which is used for routing packets around the
network. They are the ones who have cordoned off
10.0.0.0/8 and some other IPs for LAN usage.

Anyway, this document consists of several registries. I will try to cover some
of the common ones that I understand:

Cipher Suite Registry

Perhaps one of the most frequently changed registries, this registry keeps
getting new Cipher Suites added to it, and the corresponding byte value for it.

It also mentions the RFC where we can find the reference for it. The
reference consists of a short description of the algorithm, and the associated
Pseudo-Random Function (PRF) to be used. The PRF, as you might remember, is used
to generate the keys for the actual Record layer message transfer.

A common cipher suite on the web is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
It is being used on this website by the Cloudfare SSL proxy. Breaking down this
Cipher Suite:

Key exchange is done using ECDHE

Key exchange is authenticated using ECDSA

Bulk encryption will be done using AES_128_GCM which is authenticated
inherently

PRF used will be the TLS PRF with SHA256 as the hash function

This last point comes from RFC 5289, section
3.2. So, for every cipher
suite this whole thing is defined. Again, we see that the emphasis is less on
making all the data available at the same place and more on (a) making sure
there’s no implementation ambiguity and (b) making sure the system is massively
extensible.

Handshake Type Registry

If you have seen actual session
negotiations in
Wireshark (or the transcript linked), you will know that each Handshake protocol
message has 1 byte (= 8 bits) to indicate which Handshake message it is. This
registry assigns those numbers, the ClientHello is fittingly 1 and Finished
is 20.

Signature Algorithm Registry and Hash Algorithm Registry

These again are single byte values which have been defined for easy reference to
each of these algorithms, without explicitly using strings etc. NEAT! (Packet
sniffers like Wireshark take this into account and print the algorithm in the
human readable form for convenience!)

Exporter Label Registry

This is yet another registry which has a very, very specific purpose. It
stores the list of strings which can be used by protocols that wish to export
TLS’s keying material to their own layers.
This section neatly sums up the
importance and the application of this registry.

These applications imply a need to be able to export keying material (later
called Exported Keying Material or EKM) from TLS/DTLS to an application or
protocol residing at an upper layer, and to securely agree on the upper-layer
context where the keying material will be used.