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

Eric Rescorla <ekr@rtfm.com> Thu, 02 January 2020 20:12 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 AB7E512004D for <secdispatch@ietfa.amsl.com>; Thu, 2 Jan 2020 12:12:07 -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 7Vz6dmN4v8Zn for <secdispatch@ietfa.amsl.com>; Thu, 2 Jan 2020 12:12:05 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 B17C112012E for <secdispatch@ietf.org>; Thu, 2 Jan 2020 12:12:04 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id y6so33840474lji.0 for <secdispatch@ietf.org>; Thu, 02 Jan 2020 12:12:04 -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=bKjCuQAl6v/yET1LW1RYGKrWgx5w0wp5uSdbHGc+GFM=; b=Tldn1VPEmZyiJ7e3isXnUMBdibFcm2tDoB81cG8bhqKsk+KL6zKwIDHkc3ekr/GVwM SsOFEb9iH4hAbRYpESSF4Trj9vDg9Tk06+n10YzefsIjIaL3mCt1cvP4Nnlsf/ejwI04 bd2KWJdGF2rYqtVMsvG14prQI0o4+kI7ZLCUh5QKfWLjyIJC5JTto9j52vk2bnjRD3zU CD3+5kG0uz6SAW3XtS93GCx7K2vICfVZL/F5pxuezz0b9wKTvZSFoQ5tYAEBjdK3Nj5/ WOElCuQ7kZU0AuaNz/IPyFbvddV/V/RcV5bHT68Oos+ClTQHqUeB+EY/9gfPCrWAwSiu 50qA==
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=bKjCuQAl6v/yET1LW1RYGKrWgx5w0wp5uSdbHGc+GFM=; b=OhWbk75OcrrYhNYsltbBoPb3hs4aeYgxF9Wu7jiAxGl0pHz6ytOwI7L4EMPW72XgEc j0QBWAuqar/69P8MaIa80ecGtBgeKylW5oysTErZ0AAIpA4IO4TJQLaVX/raWgYw42EW jXo9huDIrhfSqZP1WYLDU7kgG31SINByWXKvoYOc1WyFzQVzuHzLdRjqSYVrDcDHwmbw HxMcC5PpKlURYNl0BH7SxT7NxkD6+zE1ZO2LpA6hLIsmeL1GSuVkTsJ411DqYZaSQRj0 rE4YFfEDCYjhSXmeCHouFw4GoMwC1TV+QZL623JvAQV+msWbwW25AmXwzqJdBWDmyQ19 tPtA==
X-Gm-Message-State: APjAAAV93WI27m1XgUQF7He7Vy+UBLX35amna3cG4u8VULXOUHZYEquK xJUY2XwZgmrFYUnV5Vjj2Yng8mrHqSsXSiXFDog77g==
X-Google-Smtp-Source: APXvYqxLsaOd0aDASLSIPF03L5/1icGyxVlmByvLKCekRk11mzXvcG67U+AnsfdZqh19ejrgHYlvV84ox3sUc7c+b04=
X-Received: by 2002:a2e:9008:: with SMTP id h8mr50855007ljg.217.1577995921567; Thu, 02 Jan 2020 12:12:01 -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> <CABcZeBOCwqhZjDmVqFUK4CmYX-=-BxT6sjrj4AUUFtZ_ZAw_aQ@mail.gmail.com> <DB512B60-8851-480A-98DE-73CF6336DC08@icloud.com>
In-Reply-To: <DB512B60-8851-480A-98DE-73CF6336DC08@icloud.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 2 Jan 2020 12:11:24 -0800
Message-ID: <CABcZeBM4r0k_tX3RageZ2oEqAKZ=XbcJqqaDpsazNxVe5tHuTw@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="0000000000005cc5a1059b2dce0c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/jZW_N2AuvrdnkNtSSx6DY7ZHFFI>
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 20:12:08 -0000

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

> 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.
>
>
> I see.
>
> 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.
>
>
> My understanding is that the Cloudflare-Google implementation generated
> two separate shared secrets. Also this draft references several different
> "ad hoc" approaches in implementations:
> https://tools.ietf.org/html/draft-stebila-tls-hybrid-design-01.
>

Well, yes, but on the wire it's packaged as a single group and key share.

https://blog.cloudflare.com/the-tls-post-quantum-experiment/

-Ekr


> Carrick
>
>
> On Jan 2, 2020, at 10:50 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> 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
>>
>>
>