Auxilliary material for TLS 1.2 - TLS Parameters - Registries

07 Sep 2017 https · internet · security · tls

Part of the TLS explanation series: Auxilliary material

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.