Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla (

[Eric Rescorla <[e-mail]>]

On Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle <[e-mail]>
wrote:
> How can it be true that it's too early to start developing a protocol
> for composite keys and signatures for Web PKI when Cloudflare and
> Google have already finished a round of experiments with composite key
> exchanges? Maybe I'm reading too much into it, but the existence of
> those experiments suggested to me that the need for composite/composite
> implementations was imminent. (I understand that the draft in question
> concerns signatures, not key exchanges, but apparently there isn't
> even a draft for the latter yet.)

ISTM that these cases are pretty different, in a number of respects.

First, the primary rationale for doing composite key exchange now is to
defend against retrospective attacks in case a quantum computer exists
in the future. In this setting, it isn't critically important to have
the PQ algorithm be the one we eventually land on, because each
connection is separately negotiated and as long as the PQ algorithm
has some security, you're getting benegit,.

The primary rationale for doing PQ authentication now (or for that
matter composite authentication) is to be prepared for the day when QC
exists and we are therefore unable to rely on classical
algorithms. However, it's not useful to be prepared in that fashion
unless the algorithm that you are deploying is the one that is
eventually selected, because otherwise you just have to start over
once the selection is made.

Moreover, in order to be truly prepared, what you need isn't
principally relying party deployment, but rather authenticating party
(in the case of the WebPKI, server-side) deployment. The reason for
this is that in the world where a QC exists, you don't have protection
until the relying party refuses to accept the classical credential
[0], and at present, any client which does so will effectively be
unable to communicate. And in order to make that happen, relying
parties will have to require a post-quantum algorithm (most likely as
a composite) and that's something I don't expect them to be willing to do
until there's widespread agreement on what that algorithm should be.


> If not now, when? After NIST crowns a winner? I don't see why it's
> necessary to wait that long given that the proposed solutions are
> algorithm-independent. And since the standardization process takes a
> while, won't waiting until then mean that there won't be a standard
> until after it's needed?

No, i don't think so.

For the reasons above, ISTM that real deployment will have to wait
until we have a selected algorithm. One could, as you suggest, deploy
some sort of multi-algorithm container, but IMO we will be far better
off just deploying new composite algorithms as if the were single
new algorithms, in the same way as we have done for key establishment.

For this reason, I think we ought to wait until there is a consensus
PQ signature algorithm, at least for the WebPKI.

-Ekr

[0] This is why this kind of composite isn't helpful in the world
where a secret QC exists not.


>