Paper rejected

I submitted a paper highlighting Fenrir to a security conference ITA-SEC.
The paper was rejected. Let’s see why and what it meas for the Fenrir project.

TLDR: no big deal, keep working.

The Conference

At the end of September I was notified that there was a new conference I knew nothing about, in January 2017, near where I live (well, near as in “almost the same region”, anyway).

What is this conference about? From the website:

The Italian Conference on Cybersecurity (ITASEC17) is a new annual event supported by the CINI Cybersecurity National Laboratory that aims at putting together Italian researchers and professionals from academia, industry and government working in the field of cybersecurity. The conference will be structured into a main track on cybersecurity science and technology, a “fil rouge” track including a sequence of multidisciplinary sessions on a specific hot topic in cybersecurity and a demo track devoted to prototypes developed by industries, research centers and universities. The conference will also feature a few selected distinguished keynote speeches and panels.

Ok, a general Cyber(sigh..) security conference. Exciting stuff, but there is not much more than that.

I guess the Fenrir project should be interesting, right?

The paper submission

So let’s check the submission requirements:

Requirements

From the website:

We solicit two kinds of submission for S&T main track, fil rouge track and demos track: original, unpublished contributions that will be included in an open-access volume of CEUR Workshop Proceedings; already published or preliminary work and position papers that will not be included in the proceedings volume. We particularly encourage submissions on new and emerging topics. Authors are requested to clearly indicate whether their paper should be included in the proceedings volume or not.
Papers have to be submitted in pdf format and should be formatted using the EasyChair style. Papers submitted to S&T and fil rouge tracks must be no longer than 10 pages including bibliography.

I guess I could fill the preliminary work. My paper is not published, I do not want to be tied or give rights to the publishers at is usually happens, too.

Don’t even care to be included in the proceedings volume. I don’t have a working implementation yet, But I would surely like the benefit of discussing my work with more people.

The paper I wanted to submit was the Fenrir paper. 7 pages long. I should be fine already!

The EasyChair style

The paper is already 7 pages long, in latex. It should not be difficult to port it to the easychair style…. or not. The style has larger margins, bigger font size, single column. The result: 15 pages… I know I always liked smaller fonts then my friends, but this is kind of ridiculous…

So some deduplication and a lot of dumbing down happened. Sections were left out, details were pointed out without the proper highlighting and discussion and so on…. Ever tried to take away a third of what you wrote?

Too many things to say, and it’s useless to talk about the high-level implications without presenting the low-level changes from which they come. So there’s not much to do that. Plus I’m not exactly as good as your favourite novel writer, too.

The paper could not be submitted immediately. The easychair website was not ready, so until (almost) the last week you just had to check the website again and again. Waited, submitted. Except the categories are not so well distinguished as they were presented. One option gives them permission to publish, the other is for already published/preliminary/position papers.

“Authors are requested to clearly indicate whether their paper should be included in the proceedings volume or not.”

Except there is no way to indicate that. Do you want me to publish something with the “I want to publish this” title?

Anyway, not much to do, pretty straightforward. You can find the submitted ITA-SEC paper here(pdf)

The deadline was extended for a couple more weeks until the 23rd October. Had I known in advance, I would have taken my time, thank you. Not like there was any communication, too.

Rejection

No communication for a month and a half, until the communication to whom got accepted (or rejected, as in my case).
Not like I was expecting some back-and-forth discussion with people, but in 1.5 months I could have changed a lot of things, or addressed some concerns. Give me at least one round-trip!

Uhm… looking at the website I still see the “submit your paper now” section, and it seems they did not even cross the “important dates” section readily…

Anyway, I got the rejection notification, with 3 negative reviews. This was my first submission, and is probably what normally happens, but I also heard about conferences with more discussion than that.

At least I have the reviews! Let’s see…

Review 1

The paper presents the key aspects of Fenrir, a new protocol whose design aims at addressing several shortcomings of TLS. I think that the motivations underlying the development of Fenrir are sound and acknowledged by both the industry and the academia. Moreover, I believe the idea of pushing away complexity from the application layer makes a lot of sense. There is potential in this line of work and it’s good to see ambitious projects like Fenrir are being developed.

Thank you.

Unfortunately, the present submission does not provide enough arguments to convince me about the effectiveness of a presentation of Fenrir at ITA-SEC. The following are my major concerns:

1) Based on the title, I was expecting a paper about formal verification and/or its application to a realistic protocol. However, the paper just says that “the protocol has been formally verified” and it does not provide any detail about this. More in general, I think the paper never takes a precise direction on what should be presented to the reader (audience). It tries to touch on too many different things in only 10 pages and, as a result, none of the key aspects of Fenrir is properly explained. I would have appreciated more an in-depth analysis of one of the aspects.

Not enough space for the formal verification. The paper had links to a public project where the verification code could be found, though. Verification was done with proverif, which is the tool to automate this things.
I did not feel comfortable making a pure-verification paper on a not yet standardized, unimplemented protocol.
Still, completely right. Which is why I was aiming to a “preliminary work” kind of paper, although there was no way to mark it as such, aside from putting “draft” in the title.

2) The paper is hard to read, due to the heavy use of technical jargon and an extensive focus on implementation aspects. I would have spent more space in discussing the design of Fenrir and the issues it tries to address. I don’t think that the technical contents presented in the paper would be a good starting point for an engaging presentation at ITA-SEC.

Hell, I’ll write a book about it. Not like I can do much in 10 pages. Guess I’ll have to take some writing lesson, too. Still, without the technical details, what will I talk about, just where the project is headed? Whenever I presented the not-technical version I always got the opposite reaction: “nice ideas, but can’t be done”; “But how do you solve this particular problem?” and so on, going bach to he tech.

Balance is hard. Either I have not learn it, or I was simply afraid of being told (again) “can’t be done”. Besides, I like bottom-up approaches. You can get the implications by yourself once you know the details. If I just give you the implication, you will only end up wandering “…but how?”

3) The paper does not discuss and compare with related work and other existing protocols.

No space. Can’t discuss OAuth1, OAuth2, SPID(italian protocol), OpenID, OpenID Connect, Kerberos, (D)TLS. And those are only the common authentication/authorization protocols I studied. For more exhaustive list I would have to include TCP, UDP, SCTP, DCCP, QUIC, minimaLT and so on… That’s a book by itself, unless I just throw jargon in your face.

On the technical side, I wonder about the backward compatibility of Fenrir. It is unrealistic to assume that everyone will start using Fenrir at some point. The research community is aware of the challenges addressed by Fenrir and there have been proposals tackling (some of) them with backward compatibility in mind. For instance, when thinking about web authentication, Origin Bound Certificates [1] and BetterAuth [2] come to my mind. I think backward compatibility should be discussed when presenting Fenrir.

This could have been explained better, yeah. There is no backward compatibility. No big deal, we just passed from http/1.1 to http2, it was so uneventful that nobody even noticed. Chrome also uses QUIC for Google’s websites, and no one notices.

But… two comparisons to other projects! I like this guy. Let’s see…

Origin-bound certificates

Michael Dietz, Alexei Czeskis, Dirk Balfanz, Dan S. Wallach: Origin-Bound Certificates: A Fresh Approach to Strong Client Authentication for the Web, in USENIX Security Symposium 2012
Can be found here(pdf)
15 pages, in two column style. Would never fit your specifications, lol :p

Maybe I should read it before… uhm… The TLS client generates a certificate for each session, and you bind the cookie to the TLS client certificate in a non-forgeable way. If the TLS connection is MITM’d, the cookie does not work.
Neat, but works only on web-based communication.
No direct support for federation, still the same certificate authority model, nothing on the transport model. It’s a neat improvement, but requires a client TLS extension. It is unrealistic to assume that everyone will have this extension ;p

TL,DR: neat, but a long way from Fenrir features.

BetterAuth

Martin Johns, Sebastian Lekies, Bastian Braun, Benjamin Flesch: BetterAuth: web authentication revisited, in ACSAC 2012
Can be found here(pdf)
10 pages, 2 columns. Even this would not fit :p

Uhm… web authentication… Why does everything need to run on top of HTTP? Javscript too? Bah, let’s go on. Haskell type safety ruined me.
I like how the paper spends two pages of critique on the current web authentication problems. I agree.
Uhm… wait, this is like half of TLS with a slightly revisited key agreement on top of HTTP. “Half”, because messages are signed, not encrypted. Still does nothing for federation,

Backward compatibility should be discussed, yes, although I find those options extremely limiting, especially compared to Fenrir.

Still, thank you for the review, I learned something.

Review 2

The paper presents an (what I believe is an overly) ambitious project, namely a protocol which is meant to overcome the limitations of TLS. While TLS has indeed some limitations, it is very widely used and deployed and it is very unlikely it will be replaced in the near future. There might exist niche applications which could benefit from the adoption of an alternative solution like that proposed by the author. Unfortunately, there is no hint of this in the paper.

Hey, nobody said anything about throwing away TLS tomorrow.
Give me paper, I shall write. The project is kinda ambitious, but the fun part is that the whole stack would be simplified.

The paper provides detailed discussion of a number of problems addressed by Fenrir. While some of them are interesting, a few of them are unconvincing.

• I don’t agree on the usefulness of incorporating support to access control in an authentication protocol. Please notice that OAuth does exactly the opposite: it is a protocol designed for authorization which happens to be used also for authentication.

And fails miserably at both. I can not honestly think about anything more uselessly complicated and full of holes than OAuth. Maybe a colander, but that’s easy to use.
Try to implement it and you will instantly see lots of required pieces that are marked optional, duplicated paths, and authentications that are so easy to bypass your average script kiddie might do it.

Let’s not talk about OAuth as a good thing. Even its author abandoned the second version right before the standardization, and required is name to be taken out. At least that should mean something, no?

Decoupling access control from authentication will result only in an authorization that can be more easily overridden, or in a duplication of features, because you have to protect the authorization data. And the easiest way to do that is authentication. Full circle. Really, take away OAuth authentication, see what remains.

• The Trust Model is unclear: who will register the keys on DNSSEC? By dropping the PKI it looks like you are throwing the baby out with the bath water…

Wait, what? Who registers on DNSSEC? I do not know, the one who owns the domain, as it should? Fenrir simply does not require a specific PKI, or trust model. It can work with any. It was written!

Is there no benefit in not paying the broken certificate authority model? We already have DNSSEC: same overall structure, without hundreds of root authorities.
No X.509 certificates means easier parsing, too. A lot easier.

Finally, the title explicitly mentions that the protocol has been formally verified, but the paper does not mention what are the security assumption and goals that have been used in the verification.

Need paper. Honestly, this part should have been extended, but the links to the code were there. The assumptions were in the “treat model” section, and there are multiple codes for different situations/tests.

… I liked the previous review better…

Review 3

This paper presents a new authentication protocol. The presentation is very technical and difficult to follow.

Guess I’ll try to take some writing lessons. Still, I’d like to see you try to summarize something like this in 10 pages.
But I am still somewhat baffled when I read “too tech”. I mean, isn’t all of this security stuff your field? Can you review any security protocol without knowing the stack it uses, too?

Placement with respect to the literature is partially missing. The title claims of a “formally verified authentication and …” but the formal verification part is not included in the paper, it is only mentioned.

Whoa, included, too? Linking it was not enough? That’s about 2.000 lines of extremely hard to read math-like code. Your appendix was limited to 5 pages, you know?
Considering how much the paper was information-packed, did not not think I just did not have space?

Acronyms are not introduced, although most of them are rather usual. FOr example RT and RTS I guess identify round trip delay. Then RTS should then be written RTs, and I think a more common acronym is RTT. It is always better to make acronyms explicit in the paper itself. Also when referring to protocols and services (for example DNSSEC) it is always better to add a citation.

Yep, RTS was a typo for RTs, Which means Round Trips (you made the very same mistake with “FOr”, so don’t make a big deal out of it. RTT means Round Trip Time. Time had nothing to do with that, so that would have been the wrong acronym. Again, I had to take away everything I could to fit 10 pages.

The paper was lacking in citations, yes, but I really do not think you’ll ever read the DNSSEC RFC.

There are some propositions for which I could not get the meaning. Some examples:

1. First proposition of Introduction: TLS is limited in which sense? If “other features are rarely used” it is not necessarily a fault of the protocol but of the way it is used

Uhm… fair, that was one part I had to take out. I guessed that by the end comparing Fenrir to TLS would have been somewhat laughable.

1. Last proposition of section 2: unclear the relationship between accounts and services

Guess what, no space. But that paragraph was there exactly to explain that. …That part seems straightforward enough for me…
I could have pointed out again that we are working in a federated environment, and thus to support multiple accounts with a single identity the only way is to require two usernames, but this seemed both redundant and… well… too long.

1. I could not get the message of the second proposition of section 4

Uhm… this was about service discovery… I guess it’s easier to see all of this for me as I am also a system administrator, and thus work with these things continuously.

Hey, give me a book and some time and I can rewrite it with pictures if you want.

1. Section 7, almost end of page. “The handshake have been named in order of robusteness against (D)DOS attacks”: what does it mean?

Holy shit, just by the names, what you think is safer, “full security”, “stateful” or “synchronized”?
The full explanation was the next part, I can’t both give a quick overview and go into details!

It is my understanding that there is no available prototype of this protocol

Which is why this was tagged as a preliminary paper.
OH SORRY THERE WAS NO WAY TO TAG IT AS SUCH. But the category in which it was filed contained the preliminary papers. So this should not have been that big of a problem.

Summary

Uhm… Ok, I’ll try to write things more clearly… But unless I gave you a paper on which you find the gzipped contents of a second paper I will never be able cram all you have asked on 10 pages, especially if those are “EasyChair” style-pages.

The good thing is that I can’t find a proper counter argument to stop or even slow down development. Which makes me happy! ^^

So I’ll keep working, and I guess I won’t participate to the ITA-SEC conference.
Apart from the fact that although the papers/tracks/panels/demos/whatever have been decided, there isn’t anything yet about it on the website, I don’t think I have the 300€+travel to spend on something where I can’t even discuss my work.

Well, I’ll be at the 33C3 (no talks, sry) if you want. More days, more fun :)

-Luker