Subject: [Secdispatch] Quantum Resiliant

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Sep 2019 12:02:51 -0400

We have a lot of interest in building PKI architectures that are secure
against quantum cryptanalysis. I see three different levels at which this
can be achieved.

Class 1: The system uses a quantum cryptanalysis secure public key
algorithm that provides all the same capabilities as traditional public key
algorithms.

Class 2: The system uses symmetric key based security with a significant
impact on capabilities as it is only possible to establish trust after
first establishing a shared secret. (e.g. Kerberos, Lamport signatures).

Class 3: The system is a traditional PKI modified to mitigate the
consequences of quantum cryptanalysis without modifications that
significantly affect traditional use. (e.g. use of hash chain notary to
protect signatures, use of shared secret KDF mixins).

As a field, we have to explore all three. And it might well be that the
short term interest is in the last. For protocol designers like myself, the
class 1 is not an interesting problem and won't be until we know how
quantum resistant public key algorithms differ from traditional PKI. We are
assuming that the problem is solved without the need for any protocol
re-engineering or with minor tweaks.

Class 2 presents some very interesting challenges as Lamport signatures are
statefull so we need a way to manage the state. Another approach that could
be interesting is to attempt a federated version of Kerberos. CAs become
Kerberos ticket granters.

So lets say I am trying to contact Amazon.com, I do this using a ticket I
have acquired from TicketCo which has a shared ticket with both of us.
Easy! OK, but how do I establish that shared ticket? Well I am going to
have to meet each CA in person or rely on some sort of federated
introduction infrastructure and we end up with multiple inputs to KDFs or
Shamir secret sharing and the like.

Class 3 looks like it is the least interesting but it is the new
'constrained device' case for PKI and that makes it a fascinating challenge
as you have to provide as much quantum security in the context of
traditional PKI approaches.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 29 Sep 2019 19:07:35 -0400

Phillip Hallam-Baker <[email-masked]> wrote:
    > Class 2 presents some very interesting challenges as Lamport signatures
    > are statefull so we need a way to manage the state. Another approach
    > that could be interesting is to attempt a federated version of
    > Kerberos. CAs become Kerberos ticket granters.

    > Shamir secret sharing and the like.

What's the business model for TicketCo?

While it might be declassez to ask such a question at the IETF, we do need to
understand where TicketCo's incentives are, in order to know if they are
aligned with the user.  We need to know in order to answer privacy and
security questions.

And also to know how it is that such an entity could come to exist at all.

It seems like it might have to wind up as a sunk cost for Enterprises, ISPs
and other Institutions.  DNS registrars?  The existing Certificate
Authority "cabal^H^HFORUM"?

Otherwise, it's gonna be facebook, google, amazon, apple, etc. (We clearly
need a TLA for this "group". See below)

Google could do this unilaterally today, leveraging Chrome and their
WebMaster interface.  Unilaterally sounds dark; someone could repaint this as
permissionless innovation if they prefer :-)
(A few rounds of AES256 has got to be faster than ECDSA operations)

A bitter-sweet point about this is that clearly governments/spy-agencies
would like to operate TicketCo, because it potentially gives them the power
they have always wanted, but math has denied them.  Bitter-sweet: looking to
the RCMP to rescue me from hegemony of Apple/Facebook/Amazon/Google/Others)
(AFAGO? AGAFO? OFAGA? OGAFA?)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-