Subject: [DNSOP] Post quantum DNSSEC ?

From: "John R Levine" <[email-masked]>
Date: 15 Oct 2019 15:11:32 -0400

I just heard a most interesting talk at M3AAWG about postquantum crypto 
and particularly about the NIST candidate algorithms.  Many of them have 
much larger key or signature sizes than any current algorithm, like 10,000 
bits or more.  Some are a lot slower than others.  Has anyone been looking 
at how these algorithms would or would not work with DNSSEC?  NIST is 
accepting comments and the talk said they particularly want comments from 
industry on how this would affect existing applications.

I can imagine ways to make things work, e.g, hashes in some places rather 
than signatures, but I don't understand DNSSEC in enough detail to figure 
out what's a show stopper.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Oct 2019 21:04:25 +0000

On 10/15/19 12:11 PM, John R Levine wrote:
> I just heard a most interesting talk at M3AAWG about postquantum crypto and particularly about the NIST candidate algorithms.  Many of them have much larger key or signature sizes than any current algorithm, like 10,000 bits or more.  Some are a lot slower than others.  Has anyone been looking at how these algorithms would or would not work with DNSSEC?  

Yes. (More specifically: https://datatracker.ietf.org/doc/draft-hoffman-c2pq/, which is very casually being worked on in the CFRG.)

Or, define "work with". Falling back to TCP for getting DNSKEY records might not be a big deal.

Or, maybe wait until NIST has gotten more through the process, given that key size and signature size are among the many factors they are considering.

> NIST is accepting comments and the talk said they particularly want comments from industry on how this would affect existing applications.
> 
> I can imagine ways to make things work, e.g, hashes in some places rather than signatures, but I don't understand DNSSEC in enough detail to figure out what's a show stopper.

Or when the show stops. Or what to do if there are multiple selected algorithms with different features (speed, size of signatures, speed of signing, ...)

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 15 Oct 2019 17:26:00 -0400

In article <[email-masked]> you write:
>> I just heard a most interesting talk at M3AAWG about postquantum crypto and particularly about the NIST candidate
>algorithms.  Many of them have much larger key or signature sizes than any current algorithm, like 10,000 bits or
>more.  Some are a lot slower than others.  Has anyone been looking at how these algorithms would or would not work
>with DNSSEC?  
>

Depends.  A 1K key is one thing, a 50K key is another.  If you are
rotating keys so you have multiple key records, and the keys are large
enough, what happens when the result packet is bigger than 64K?

>affect existing applications.

The talk was by Brian LaMacchia, who opined it would e useful to send
in some comments about how various increases in key size, signature
size, and signing or verification speed would be likely to work with
DNSSEC.  It sounds like they're paying a lot of attention to TLS in
their algo evaluations, a lot less to DNSSEC or DKIM or other
protocols.

I'll see if I can get his slide on the key and signature sizes for the
candidate algorithms to be roughly as strong as a 3K RSA key.  One of
them would need a 500,000 bit key which makes me wonder what they were
thinking.

---

From: william manning <[email-masked]>
Date: Tue, 15 Oct 2019 14:44:28 -0700

this crossed my radar in 2016 during a quantum networking retreat at Torry
Pines.  Talking with some crypto people in 2017, these notes kicked off
adding a new algorithm for my test universe.
---

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3040224
https://arxiv.org/pdf/1509.02533
ieeexplore.ieee.org/iel7/6475439/6483185/06483432.pdf
https://www.semanticscholar.org/paper/Media-Landscape-in-Twitter-A-World-of-New-Conventi-An-Cha/12dec1541d7e1528d5cc5ca5216c7c2f787387db
https://www.cl.cam.ac.uk/~jgd1000/metaphors.pdf
courses.csail.mit.edu/18.337/2015/docs/50YearsDataScience.pdf
https://www.gov.uk/government/publications/the-exchange-and-protection-of-personal-data-a-future-partnership-paper

https://royalsociety.org/~/media/policy/projects/data-governance/data-management-governance.pdf

https://royalsociety.org/~/media/policy/projects/machine-learning/publications/machine-learning-report.pdf
.

The security arms race continues….
Aging Crypto is begining to show Kracks

Many years back, the observation was made that we (the industry) could
monetize security by sprinkling “security pixie dust” on everything which
would put security everywhere.  Shortly after that observation was made,
sane people admonished against the practice of putting security
everywhere.  But the money won and today there is a security option at
every point in a communications path.  A recent, high profile event was the
introduction of KRACK (1), which shows the vulnerabilities in WPA2, a
wireless link-level protocol that is used in all modern “protected” WiFi
networks & systems.  The ostensible problem is not the vulnerability
itself, but that the protocol is widely deployed and embedded in nearly all
WiFi gear made in the last 15 years.  To fix the problem, one has to
upgrade BOTH ends to a system that has not been hacked.  Or decide that
link-level encryption is not a generic panacea for security.

This is but one recent example of a history of successful attacks on
cryptography that has found its way into the systems we use and depend on
daily.  And here in lays a serious problem.  Our lives are infused with
pervasive cryptography that is broken outright or has serious, known
wealness. Not only us, but those that govern us are affected in the same
ways.

This week in Washington DC, at the Cyberweek conference, one of the items
being discussed was when does all our crypto break in a trivial fashion.
It seems that most folks had thought that changing the key size will give
us some breathing room but after this past weeks discussions, it is not so
clear that we have time. (2)  A takeaway was; “When quantum computing comes
of age, even the most secure encryption on the planet likely will be
shattered.”  By some estimates, we have already past that threshold, others
give us 60 months or so.  Still, a very short time indeed.

Why are we not better prepared?  Well NIST has been thinking about the
problem. They even held a workshop on the topic in 2015 and a request for
proposals due next month. (3)  There are plans to start a standardization
process next year.  But if all our existing systems are vulnerable, what
options are there?   I’ve asked a few security aware friends and other than
submissions to NIST (or similar work), it seems we are going to be stuck
with some varient of  the McEliece Cryptosystem  (4) (1978).  And for the
protocol folks out there, this is going to be HUGE. :)  Heads up folks.

1) https://www.krackattacks.com/
2) https://www.fedscoop.com/quantum-computing-coming-encryption-matter/
3) https://csrc.nist.gov/projects/post-quantum-cryptography
4) www.math.unl.edu/~s-jeverso2/McElieceProject.pdf
-----------------------------------------------------------------------------------------------------

On Tue, Oct 15, 2019 at 2:26 PM John Levine <[email-masked]> wrote:

> and particularly about the NIST candidate
> >algorithms.  Many of them have much larger key or signature sizes than
> any current algorithm, like 10,000 bits or
> >Yes. (More specifically:
> https://datatracker.ietf.org/doc/draft-hoffman-c2pq/, which is very
> casually being worked
> >on in the CFRG.)
> >
> >Or, maybe wait until NIST has gotten more through the process, given that
> key size and signature size are among the
> >many factors they are considering.
> >
> >> NIST is accepting comments and the talk said they particularly want
> comments from industry on how this would
> >affect existing applications.
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>