Encryption

What are the differences between Fenrir and TLS?

What about other systems like QUIC or minimaLT?

To find it out, let’s quickly check how things are done in TLS…

TLS

TlS is bloody complicated. At least from the administrator point of view. After a lot of years, strict ciphers must be selected, or we risk losing our security.

The latest version of TLS today is the TLSv1.2; discussions are starting for TLSv1.3.

For all details, refer to the wikipedia page. For now, let’s see some general stuff:

• An handshake must be done to exchange keys.
• The handshake supports virtual hosts (unlike SSL)
• Once we have the key, we use the MAC-Then-Encrypt mode (AEAD only from TLSv1.2)
• The protocol seems very extensible
• The user is provided with a single bytestream, there is no multiplexing

The handshake

Let’s start from the handshake. Like QUIC, or minimaLT, Fenrir is a [transport protocol] (/2014/12/04/Transport/), too, which means we have to somehow reimplement what TCP gave us. Since that already means we need some form of handshake, in Fenrir we do both connection and encryption handshake together.

This saves times in the form of RTTs, and protects all levels of the connection, so we don’t have to worry about spoofed TCP RSTs.

Usually there’s only one type of handshake per protocol. TLS has a 3 RTT handshake, necessary to decide what ciphers/exchange to use, exchange the keys and then authenticate.

While Google incorporated the handshake in its QUIC protocol, they realized a lot of parts could be reused. So, while providing something only marginally less strong (forward secrecy is less strong), they managed to speed up the connection down to 0-RTT. But in the end, there’s no much difference with the TLS handshake.

I will talk more about the handshake in an other post, as it requires a more in-depth discussion.

For now, let’s just say that Fenrir supports multiple handshakes, from a TLS-like, full-security, to a minimum 1-RTT, very similar to minimaLT.

The virtual host problem

One of the (much asked for) improvements of TLS over SSL was the support for virtual hosts. That is, the ability to run multiple hosts, each one with its own certificates and options on the same ip:port.

This does not mean that it’s done in secrecy. If you sniff the data in an https connection, you will see what website the browser is connecting to, and even if it is attempting to use the SDPY protocol. Then the certificates are exchanged and everything gets hidden.

I like virtual host support, but I like secrecy even more. So I decided to keep both. This can be done in a new protocol like Fenrir, it can’t be done in TLS.

The reason is simple: in TLS you need to know in advance what port you will be connecting to. By the time you are starting your handshake, you already decided which IP you will contact, and what service (443, https almost always, today).

So there are only two ways to handle different certificates on the same handshake:

• try all the certificates in your possession
• write what virtual host you are contacting in clear text.

The first option is obviously a joke, so the second one was the only left.

But in Fenrir things are bit different. I didn’t have any legacy to continue.

The connection starts with a DNSSEC query. (or any other secure way, but for now, only DNSSEC). Historically, this meant that we only got an IP address. Instead we have a base85-encoded binary, in which we found lots of informations, including the ip address (and eventual udp port) and public key of the authentication server.

We don’t have to guess the service anymore

This is a big deal, we can now move any service on any udp port, so there are less limitations for system administrators, and service names are no longer sent in clear text.

Almost.

In reality, we still need to identify the public key used in the connection with the authentication server. By sniffing the traffic, we could thus understand that somebody is trying to contact the authentication server for domain X.

But this still does not identify the service that the user wants to connect to.

The identification of the requested service (mail, web, whatever) is sent inside the encrypted connection, and can not be extracted. The authentication server will tell the client the ip address of the service, the client will connect to this ip, and all that an eavesdropper will be able to understand is that you are talking to that ip.

What service you are using is, however, hidden.

Encrypt-Then-MAC

Encrypt-Then-MAC is the preferred choice nowadays, and the other way around has brought a lot of problems to WEP, for example.

Still, TLS still uses the MAC-Then-Encrypt mode. It should be changed in TLSv1.3, finally. Note that the RFC7366, introducing the Encrypt-Then-MAC mode, is from September 2014.

As the stack overflow link above as a good discussion about this, I won’t go further.

Fenrir is designed to work with AEAD and Encrypt-then-MAC modes.

Extensibility

The only thing that saved SSL and TLS until today has been its flexibility to accept new ciphers, and to disable old ones.

You might think that this is a given for any security protocol, but I couldn’t find anything like that in the very recent minimaLT.

Going back to TLS, it is actually difficult to disable old modes in all applications (postfix still doesn’t seem to support multiple certificates for its smtpd) and it is difficult to choose the right browsers and platforms to support.

Still, as it is very important, in Fenrir almost everything can be changed, starting from the initial handshakes.

Starting anew will help in simplifying the mess that the TLS options have become.

An architectural change that Fenrir introduces is the Client Manager, an application that manages your authorizations for your whole device.

To understand why this provides extended flexibility, think about what happens to today applications: you tie your application to a library, and you use only some functionalities. X.509 certificate login is uncommon ‘cause you have to set it up in different ways in every application. Maybe the software was not written by security experts and is tied to a subset of handshakes. Maybe the library is statically linked and is no longer updated. Maybe…

In Fenrir the Client Manager handles the handshakes, authentication and authorizations. Suddenly your application can use almost all the latest advancements in the protocol without even updating its linked libraries.

With Fenrir, your preferred authentication method can be used with all applications, even if you set up something strange like a password-with-smartcard-and-biometric kind of login.

In short, by keeping the extensibility of the protocol, and decoupling the transmission from the authentication, I have finally made it possible to actually use all those extensions that will be created, so that legacy or poorly written software or user interfaces will not block advanced usage of the protocol for everyone.

Multiplexing

TLS was born to be used on top of TCP. Then someone needed UDP and DTLS was born, but there are no substantial differences.

SSL and TLS didn’t bring anything new to the TCP stream. That might have been because people liked the separation of layers, but it also meant that TLS got stuck with a single stream of bytes, that doesn’t even handle the beginning and end of a user message, or multistream.

Fenrir instead was born with the flexibility of SCTP in mind, and thus incorporates the possibility to manage different streams and to manage user data boundaries.

This doesn’t concern encryption per-se, but it shows again how trying to follow too much the OSI pile can be limiting.

Public key exchange

One thing that might change in the (close) future in Fenrir is its handshake, especially regarding the supported public keys.

Just like in TLS, different public key types can be used, and each must will be assigned its own id, but in Fenrir we have one problem that was not apparent in TLS: key size.

TLS was built on top of TCP, so they didn’t have to care about key size. It might have been long, but spanning across multiple packets was not a problem.

The current implementation of Fenrir does not work with keys long enough to span multiple packets. This is difficult to resolve since I am also keeping an eye on what each modification might do in terms of Denial Of Services.

Although not completely resolved, I already have a couple of ideas in mind, but don’t worry too much – an 4096bit RSA key means we have a 512 bytes key, while packets have a payload between 1280-1500 bytes (think ipv6).

And ECC keys are much, much shorter! So why do we still need to span between multiple packets? Mainly because some new public key encryption might require long public keys, for example like the lattice-based (supposedly) resistant to quantum computer cracking.

The fun part is: everything is so extensible that it’s not a problem I need to take care of now, even though the earlier, the better :)

-Luker