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

Eric Rescorla <> Thu, 26 December 2019 01:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 989AF1200DE for <>; Wed, 25 Dec 2019 17:58:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2pyVwvtfX8yd for <>; Wed, 25 Dec 2019 17:57:58 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 064BF1200B5 for <>; Wed, 25 Dec 2019 17:57:58 -0800 (PST)
Received: by with SMTP id a13so23621155ljm.10 for <>; Wed, 25 Dec 2019 17:57:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=59mm5u8OJ3JQK/NstsGDyAKnRO8OOAqAcl5FvuICpdo=; b=CJMijBSB8egxURCPZoJgexiByU52GCcZIJPcpjgIOfqcXVTAGG0dDagPPaFNlWUnu0 UYAQDsWlXORLm6DC0qfe5BtCTifySQLgIOA0Pl0GEGevkdG62yJNlKFA2y0LZ0w3pMB/ B5YR4qF/Mhl+o1q9DBMd4Ly3eF30nvcyQ5h/Ea6ogZLCUu/yx1Ti061JMxTnFONm6k8c wOV6fLZaDr3nt29AYCdCS5yX9FHGBbryyEl+uQuzQeS4Uv7NEjE4HONJ5qQ6cLaXhVuF m+X0o/D/BOIrA9Gld7u33o3Yf5WzwzvSRUJlH/NZUC+zlFRdykNS0iEJPUu+dwM1h9Zi Z8Qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=59mm5u8OJ3JQK/NstsGDyAKnRO8OOAqAcl5FvuICpdo=; b=T2U0RRkJNmWhhv4q8ycRPpS3oA4sHZmeRVh/R+tB/fe8oOeQ8/VnouJqgO3W5gaUhX JcwAdZzTXitQfjYWOwWzT+QL9TCRpptgEdAFR0YBB+hQEEjEQtOwSsaYHogiuZ0cVrpL 8UAPd0I2aqPvc8m1mQQXyq1eI5WxZvG0e5TXHi0WigbQRJaUaPMzm70/ZBtOJod4n/d6 uH1m4HGcHawhWII8dpnlZKndW6FzfbZvyFeq/vL7vEWeOriUL/LkEeuf5FF0Vy37M2HH Jcrq8US+icFF/BOq3JVnRD91zT1Cfel+Kg6BUpvwS53Rg0VvvYE3PXe7xW0ngCrUSMNr l9Bg==
X-Gm-Message-State: APjAAAUsqbhLWGFeX7VIJNTV6yURNj8oUkKZQx+3fKtyKkqaoQmHzv76 fKfO2E/unkMHkqt9BeKgtK3oYNiV609u1Trp/snedA==
X-Google-Smtp-Source: APXvYqz1bJgIjdBLLAnMmHzA2A2SqcFWTzR7yYkGDwRwf3eXqQmjEWiOKANnwT8m0nmr87I0zAoWbY+rFHSnHPVlrNA=
X-Received: by 2002:a2e:95c4:: with SMTP id y4mr24661644ljh.38.1577325476077; Wed, 25 Dec 2019 17:57:56 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Wed, 25 Dec 2019 17:57:19 -0800
Message-ID: <>
To: Carrick Bartle <>
Cc: "Salz, Rich" <>, "Dr. Pala" <>, IETF SecDispatch <>, Stephen Farrell <>
Content-Type: multipart/alternative; boundary="000000000000b2780b059a91b49c"
Archived-At: <>
Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla (
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: Thu, 26 Dec 2019 01:58:01 -0000

On Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle <>
> 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.


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