Re: [DNSOP] [Ext] Post quantum DNSSEC ?

[william manning <[e-mail]>]

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 <[e-mail]> wrote:

> In article <[e-mail]> you write:
> >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.
>
> 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?
>
> >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.
>
> 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.
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>