Hello #NDSS20! That keynote was a ton of work to prepare, so I thought I'd squeeze some extra value of by posting key points from the talk here!
Here we go!
(For those of you at home, NDSS is one of the "big four" top-tier academic cybersecurity conferences.)
<thread>
Here we go!
(For those of you at home, NDSS is one of the "big four" top-tier academic cybersecurity conferences.)
<thread>
The focus of my talk was technology transfer.
How can we align incentives in the academic community, to encourage researchers to design systems that actually get used in the real world?
This is a key question in 2020, where infosec is everywhere.
How can we align incentives in the academic community, to encourage researchers to design systems that actually get used in the real world?
This is a key question in 2020, where infosec is everywhere.
Here are two metrics that I think should matter, when judging academic infosec research.
Notice that novelty is not on this list.
I don't think the community gives enough credence to these metrics.
Notice that novelty is not on this list.
I don't think the community gives enough credence to these metrics.
To illustrate this point, I gave two examples from my own work. The first example was our work on NSEC5 (a privacy solution for DNSSEC), which you can read about here.
eprint.iacr.org/2017/099
eprint.iacr.org/2017/099
We began working on DNSSEC privacy.
As part of this work, we developed a spec for a verifiable random function (VRF).
Due to challenges related to integration, we didn't get very far with the work on DNSSEC.
But our VRF work took off!
datatracker.ietf.org/doc/draft-irtf…
As part of this work, we developed a spec for a verifiable random function (VRF).
Due to challenges related to integration, we didn't get very far with the work on DNSSEC.
But our VRF work took off!
datatracker.ietf.org/doc/draft-irtf…
@Algorand @Libra_ Just a note that we got zero academic points for doing all the VRF specification work. The research paper is still unpublished!
Here's the paper: eprint.iacr.org/2017/099.pdf
Here's the spec: datatracker.ietf.org/doc/draft-irtf…
I think academics need to give more credence to specification.
Here's the paper: eprint.iacr.org/2017/099.pdf
Here's the spec: datatracker.ietf.org/doc/draft-irtf…
I think academics need to give more credence to specification.
... a direction in which
✅zone enumeration is feature, not a bug [RFC8198]
✅supports dynamic computation of DNSSEC responses
So, basically the opposite of what we optimized for.
This made NSEC5 adoption harder. Since the system is essentially a moving target.
✅zone enumeration is feature, not a bug [RFC8198]
✅supports dynamic computation of DNSSEC responses
So, basically the opposite of what we optimized for.
This made NSEC5 adoption harder. Since the system is essentially a moving target.
Nevertheless, NSEC5 is still the best solution for certain usecases! NSEC5 prevents zone enumeration, even if the nameserver is compromised. No other solution can do that.
But in a hairy system like DNSSEC, all these moving parts have made integration of NSEC5 more difficult.
But in a hairy system like DNSSEC, all these moving parts have made integration of NSEC5 more difficult.
So in summary, we started in DNSSEC, moved to verifiable random functions (VRFs), and finally found adoption in proof-of-stake blockchains!
This is all because we fully specified our VRF.
Academics, give more credence to specification!
This is all because we fully specified our VRF.
Academics, give more credence to specification!
Next, I gave another example from own work which was recently published at Asiacrypt'19!
eprint.iacr.org/2018/057.pdf
This work solves a simple problem. What if the keys to your crypto system are maliciously chosen?
eprint.iacr.org/2018/057.pdf
This work solves a simple problem. What if the keys to your crypto system are maliciously chosen?
We found a simple solution.
Send a short "certification" that the public key was correctly chosen, along with the public key.
Check the certification once, and you know your public key is good!
Our scheme works for RSA and Pallier, and was adopted by @UnboundTech_ & @ZenGo.
Send a short "certification" that the public key was correctly chosen, along with the public key.
Check the certification once, and you know your public key is good!
Our scheme works for RSA and Pallier, and was adopted by @UnboundTech_ & @ZenGo.
@UnboundTech_ @ZenGo Why was this work successfully adopted?
Well, apart from being secure and efficient, our scheme is
✅ specified, and
✅easy to integrate (just add our certification to your pubkey - with no other changes to your cryptosystem!)
Easy. And it works.
Well, apart from being secure and efficient, our scheme is
✅ specified, and
✅easy to integrate (just add our certification to your pubkey - with no other changes to your cryptosystem!)
Easy. And it works.
@UnboundTech_ @ZenGo Finally, someone asked me during Q&A how academics could go about specification in an efficient way.
I talked about this at IETF'102 at ANRW'18.
You can watch the talk here!
I talked about this at IETF'102 at ANRW'18.
You can watch the talk here!
@UnboundTech_ @ZenGo So, in summary, #NDSS20 gave me a soapbox and I decided to use it!
I hope I convinced you to think about quality of specification and ease of integration when you are next reviewing an academic infosec paper!
Thanks for listening!👩🏫
</thread>
I hope I convinced you to think about quality of specification and ease of integration when you are next reviewing an academic infosec paper!
Thanks for listening!👩🏫
</thread>
Thanks #ndss20 for the invite and stonehouse photography for the photos!
And of course, thanks to all my coauthors and especially to Leo Reyzin who coauthored all the works I discussed today.
