Re: [Secdispatch] Quantum Resiliant

Michael Richardson <> Sun, 29 September 2019 23:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A0251200FB for <>; Sun, 29 Sep 2019 16:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W0JR3dLzS2Wf for <>; Sun, 29 Sep 2019 16:07:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 76A8F120073 for <>; Sun, 29 Sep 2019 16:07:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 223B83897D for <>; Sun, 29 Sep 2019 19:05:37 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 91176373 for <>; Sun, 29 Sep 2019 19:07:35 -0400 (EDT)
From: Michael Richardson <>
To: IETF SecDispatch <>
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Sun, 29 Sep 2019 19:07:35 -0400
Message-ID: <6814.1569798455@localhost>
Archived-At: <>
Subject: Re: [Secdispatch] Quantum Resiliant
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 29 Sep 2019 23:07:39 -0000

Phillip Hallam-Baker <> 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.

    > So lets say I am trying to contact, 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.

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)

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-