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

Eric Rescorla <ekr@rtfm.com> Thu, 02 January 2020 18:51 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202D9120142 for <secdispatch@ietfa.amsl.com>; Thu, 2 Jan 2020 10:51:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9d7bv_NUbCP for <secdispatch@ietfa.amsl.com>; Thu, 2 Jan 2020 10:51:37 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D38120123 for <secdispatch@ietf.org>; Thu, 2 Jan 2020 10:51:36 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id o13so30222649ljg.4 for <secdispatch@ietf.org>; Thu, 02 Jan 2020 10:51:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dKr7zOkf0MzvIF592FObJFeiKQPbBIKX/tZzOvHQSgY=; b=uxpAa4NM/6BmUH+uFrRpnw/w3iZDcMyO0yfaGv0UoITVhxUoS5vNfCAAT4GO8UjzuM TjWG8GISZYprLXzCIUwVEENxiqao1HltLRJ9HYZlCGG8dPgdpNmx+g8iPwLUuHtB9i95 g9DXAXmSt+2JvOZ7b/r5/Qok8wQYbxUYsMtOdHg2jnwr6pL4RaoPjma+mhuKhQwOXSH+ wapEic/acIuY0eJjIY/MT2GD2uFBQe8U+MKNNgWYKOaXnEI0B7g0Sd3pnAIhovhi/596 QilrGWRLPqIEq37u2yaJnio7nHnN3lYaZ2lg4L4c9AjvjOXpDt3Ip+IuiQAb/KpOnT2l 3NHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dKr7zOkf0MzvIF592FObJFeiKQPbBIKX/tZzOvHQSgY=; b=NaaaBIH/qDgaVdklj+OIM96jntFH8PL2/GUBCoaAVUq+Y7q/vqx84yQnSRsigSg5Qp eC7N1mMIr0aVhlFHL7f0npn1gghLdKgzDgIUj+28jTLJ4ksHxkt1OI1fEk1IY2YSyFuU VwcVM0buxC6g/qMQ0iZifCoCOSS+Yj5o1xtMjCbeeD5CiUlq07d4LoHNwH+xnzl809uN qRdKnKgevChPHc5r9AtsW3bQIEDDtd5kYuhF4D0Dw3MpJiPlLnVn00ANaFoL9fLO/Lpi Z9n2GPIqsBOSIJq2+JGhq1TG/u+iPW9/oBxKd3JphIsVvOACOWmUmAxB4iToA2P7Y6zJ GZww==
X-Gm-Message-State: APjAAAWJu478mfUZbjaFgsa4XQU44An8gAXizdbbPDABvry3Hmh57UIk knkNFcVniqJBSXxWEpvDN948qRQzqLzDscQMZAZBwA==
X-Google-Smtp-Source: APXvYqx/KQhqHXgoLFHcY6Kh6+WE+X14+YBT8r7J3Pi1/bkyj99M1x2gWfk+7DhWktnhyV1iRdH3iZXGkA3NkZrUNQE=
X-Received: by 2002:a2e:870b:: with SMTP id m11mr48035782lji.93.1577991094614; Thu, 02 Jan 2020 10:51:34 -0800 (PST)
MIME-Version: 1.0
References: <12eed4ff-edd2-7f70-9460-fc86dcbab927@openca.org> <CABcZeBPbAgBfC6Et+OKQi2=GwsyeyKEKfW5GG=StUepQwy+f0g@mail.gmail.com> <7999ebac-c9c1-eb4f-d9f7-2ba814a3b331@cs.tcd.ie> <78997490-c5ae-c856-6e26-0f79c7733ca3@openca.org> <CABcZeBM5WgpcBP4axBvzWaxKU=JA-K-4qiVxhhO1+HzFf246aw@mail.gmail.com> <95B2FAB7-66FA-44F2-84F8-FA23737AA38F@akamai.com> <CABcZeBM06FEiMkDVhOPnQggHCG7DeOVkNLNn1w2wDnhy6rJuhg@mail.gmail.com> <07119213-1702-4742-A34F-EDEDBF294FCF@icloud.com> <CABcZeBO7DSn3vaghfk5ADSEM-Wx50HtQHtN_OKNk5zeWkuXJ0Q@mail.gmail.com> <3FFD9FD4-10E3-41B5-B086-A0AF17EF6899@icloud.com>
In-Reply-To: <3FFD9FD4-10E3-41B5-B086-A0AF17EF6899@icloud.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 2 Jan 2020 10:50:58 -0800
Message-ID: <CABcZeBOCwqhZjDmVqFUK4CmYX-=-BxT6sjrj4AUUFtZ_ZAw_aQ@mail.gmail.com>
To: Carrick Bartle <cbartle891@icloud.com>
Cc: "Dr. Pala" <madwolf@openca.org>, "Salz, Rich" <rsalz@akamai.com>, IETF SecDispatch <secdispatch@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="000000000000a76234059b2cae8a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/8U2Qo3eomwdIKIBMXwzcOWKRaAo>
Subject: Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla (
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jan 2020 18:51:39 -0000

On Thu, Jan 2, 2020 at 10:45 AM Carrick Bartle <cbartle891@icloud.com>
wrote:

> 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.
>
>
> Just to be specific, do you mean, for instance, all the certificates with
> the PQ algorithm that wasn't chosen would have to be revoked?
>

Probably not.

At a high level, there are two possible designs:

1. A certificate which has a composite signature in place of the classical
signature and thus cannot be validated by old clients.
2. A certificate which has a PQ signature somehow attached in a way that it
leaves the classical signature valid (as in an extension).

In the former case, every server would need two certificates (one composite
and one classical) and use signature_algorithms to distinguish which one to
use. Once clients stopped liking the old PQ algorithm, then those composite
certificates would become irrelevant and just be unused. In the latter
case, the certificates would continue to be valid and the client could just
ignore the PQ part of the signature.

What "start over" means in this case is get to the point where there is a
critical mass of client and server deployment, a process which takes time.

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,.
>
>
> In that case, would it make sense to take the next step with drafting an
> intended standard for composite key exchanges (that is PQ
> algorithm-agnostic)? If not, why not?
>

I think not, at least for TLS. The consensus of implementors seems to be
that it's better to just cast composite algorithms as if they were new DH
groups, so there's not a huge amount of leverage in a generic mechanism.

-Ekr

Carrick
>
>
>
>
> On Dec 25, 2019, at 5:57 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> On Mon, Dec 23, 2019 at 8:38 PM Carrick Bartle <cbartle891@icloud.com>
> 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.
>
>
>> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
>
>
>