Frequently Asked Questions

The “Why new stuff?” category:

We have OAuth, why something new?

I have personally implemented OAuth and studied its RFCs.

OAuth1 is a mess, and OAuth2 is much worse. New standard build on top of these are more or less the same, just with easier frameworks and more complex (if any) proof of security.

Everybody uses it, I know, but only for a lack of a real alternative. The alternative would be to design something from scratch, or use OpenID. OpenID is actually simpler than OAuth, but never took enough traction, maybe because the federation and the redirect between web pages scared people, I’m not sure.

The OAuth1 specification lets you do things in different ways: this confused people and created problems when people started realizing that the “optional” stuff was not really that optional. It also forces you to use some (basic) crypto and hash tricks, but its main problem is that it is not portable. By this I mean that your implementation for site1 will never work on site2.

The solution? Make it worse in OAuth2. Make everything optional, make everything even more incompatible between different domains.

OAuth should die The main author declared it a failure and asked for his name to be removed from that some 3-4 months before the standardization.

…I could talk for hours on why I hate OAuth, and I promise you a specific post on the matter… expect a long one :)

Why reimplement stuff from layer 3?

Protocol stacks are good. They give you an abstraction, so first you have a small piece of software that does one thing, then an other one does an other…

The protocol stack is just an other form of modularization. But It has big limitations, and you can easy see them:

• TCP gives you a connection. it’s insecure
• TLS gives you secrecy, but you can still reset the underlying TCP connection.
• TLS is secure, but there are no standard ways to do UDP+secrecy/security.
• TCP/TLS gives you a session, but HTTP destroys it, and you have to reimplement it. Guess who has to track the session now? That’s right, you. You weren’t supposed to do that. I bet you are tracking both a session id and the OAuth token. Two session id in one? Nice…

The list can go on. This is not modularization. This is patchwork. I’m not saying it doesn’t work, but the overall effort to keep things together is much higher, and you still need to be an expert in all those protocols. there is no abstraction

And you have lost all flexibility and underlying protocol features.

So the ISO/OSI pile is wrong?

Not completely. The idea is correct, but no one ever used a strict abstraction like the OSI protocol pile. Just think about TCP,UDP, which require the IP and the port to track a session.

Abstractions are good, but combining the transport, session and presentation layers (4-5-6) in Fenrir yields extremely short, efficient headers, more security and shorter connection setup times.

But what if I don’t need encryption and authentication?

Fenrir can avoid encryption if you want(for now). You can have anonymous connections. But in today’s world, can you really say you don’t need authenticated connections?

I’m talking about knowing that the data you have comes from the right server or client. You need that. Even when you think you don’t. And to have that, even today, you need a full protocol stack. Just for that. Why don’t we simplify things a bit? Encryption is not that hard on hardware anymore, anyway.

Why not just use QUIC?

See the above answers. It would be a patchwork. I wouldn’t be really able to use the abstraction of QUIC, I would have to track things inside QUIC. I wouldn’t be able to fully utilize the features of the protocol.

I also have some reservations on the QUIC protocol, I don’t like how they do a couple of things, although it doesn’t mean it is not secure enough.

The more Technical questions

Why C++11, and not {insert_language_here}?

Note: Due to lack of progress, the status of the current implementation and the maturity of the language,I am seriously considering starting from scratch with Rust

Many people do not like C++. And with reason, as lots of things can go wrong, so you need to pay attention, especially thanks to all the sub-languages, which are all turing-complete.

But the 2011 version improved a lot. To the point where the programming style has to be changed in order to call the ode real “C++11”.

I’m still learning all the intricacies the new version, but I like it.

As long as the rules are clear, and not all the features of the language are used. Real C++ purists might not like the limitations we use while coding Fenrir, as it brings the code much nearer to C. But that’s exactly what I want: a language where I don’t have to double check every range for out-of-one errors, where I don’t have to worry about the strlen() insecurities, that stills lets me go down as low as C if I really need it.

In short, I don’t think it’s a bad language. It’s like goto: if used correctly you can write exceptional code, but if used every time you can, any way you can…

C++11 does not mean pure object-oriented design, does not mean that I won’t use a pointer where I can, etc… It will be a case-by-case until I can form a good enough document. For know, I am starting from a modified version of the Google guidelines