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

Eric Rescorla <ekr@rtfm.com> Wed, 08 January 2020 16:44 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 0EB3C1201EA for <secdispatch@ietfa.amsl.com>; Wed, 8 Jan 2020 08:44:27 -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 5QvKGtnxZgDU for <secdispatch@ietfa.amsl.com>; Wed, 8 Jan 2020 08:44:24 -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 55EE8120898 for <secdispatch@ietf.org>; Wed, 8 Jan 2020 08:44:23 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id m26so3964338ljc.13 for <secdispatch@ietf.org>; Wed, 08 Jan 2020 08:44:23 -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=GZ/odt34TDKKnWPFssCO6pd+sSzCNg+p/UNe6xECIwo=; b=ao8g3MoVvYMOtrcUzP5dUDH/wVOLRg1nWQEwTomreeXGEVPKuKBUzEjY+uo2001IJ9 FuYPG6Ml152538ehrRWjeH9vOHoU4uGtyrYHHxoBj92vgnLUNF8YTaQzMtSuRh5MhMMg Ds/JGUikHv0T0Z6i0pKntTnYfFjomCrH1xyWRnZv+ViYvML1vLYTIWrkEe/OJUgiOQuq znKcukgVzHk+IKAKZGpU9LYfF13m49tsb5bDPKYFc83Tx+gLSKxgX7AoIVHxbm6r+yiW YvoupFkzNOHgrklTo1jFjbwPSO5tRapWsxTNFd18lvinEbn7nmwxPK6zALwppk8bOMRL c+/g==
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=GZ/odt34TDKKnWPFssCO6pd+sSzCNg+p/UNe6xECIwo=; b=geLI8x5JWuDTsjoWVD7mMnPMK+p+3kbK0yhVO25ReV6297seV9EiA5P/lYyOCVJhk2 WXGMPA/Us+bqif6Tth1Q2cGV46XbvGXKdQJXD9Bjhl+9jwDb8INsoflxNePGDvq32Err a9qZ3rz2XepesuLjWJXIx4rp1N/OzZFCE740po7s88L7mWoLl6Edi9R0SuxAd8iQnmH+ 2X9/TjMQ1nHpNACdKK7n1oon0zVB+u1KPGyt335/bc0yqCVq7WJGNregtyu7s96+OZPR GFe8mKC62jMqRokVLZzrXZgEAkKuc9yx9xnCcTbjG8dTfJJIDsYhUSEf10U33R/RYIjk geFA==
X-Gm-Message-State: APjAAAVDhB4RNDoZho3lpSr3ltzaF2tqQWnDwWtfHRD+TbmFjv2I/Imc 5ZfRoKmya7QLy5Ocn0QQhUc1xIP7+mpIC4IueygU+g==
X-Google-Smtp-Source: APXvYqx5C5ylVOvoSSniJGSXk36QmJLdaj/YBoaZe96HxvuuYpEIrDtoBjzR5aYoqZca+sKgOdWAq6T/n5PPzPJyuTQ=
X-Received: by 2002:a2e:95c4:: with SMTP id y4mr3523822ljh.38.1578501861590; Wed, 08 Jan 2020 08:44:21 -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> <CABcZeBM4r0k_tX3RageZ2oEqAKZ=XbcJqqaDpsazNxVe5tHuTw@mail.gmail.com> <DM6PR11MB38835E0C6C931C9E9BE676689B3E0@DM6PR11MB3883.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB38835E0C6C931C9E9BE676689B3E0@DM6PR11MB3883.namprd11.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 8 Jan 2020 08:43:45 -0800
Message-ID: <CABcZeBN5p9x60cKOfdj1-suHb_d0y4tKbFbaEvhWaVPAE+aGCA@mail.gmail.com>
To: Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com>
Cc: Carrick Bartle <cbartle891@icloud.com>, "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="000000000000bce8c6059ba39a99"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/7CAtpxjmVK9g6VX74wKJVxm2174>
Subject: Re: [Secdispatch] [EXTERNAL]Re: 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: Wed, 08 Jan 2020 16:44:27 -0000

Mike,

The context of this thread is my comments at the mic that I didn't think
this made much sense for the WebPKI. I haven't fully thought through the
non-WebPKI cases.

With that said, if you are concerned about long-term signatures, I don't
really understand the point of a hybrid scheme, given that we don;'t really
have that high confidence in any PQ signature system other than hash
signatures, so why not *just* use hash signatures?

-Ekr



On Wed, Jan 8, 2020 at 8:26 AM Mike Ounsworth <
Mike.Ounsworth@entrustdatacard.com> wrote:

> Ekr said:
>
>
>
> 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.
>
>
>
> I agree with your conclusion about composite breaking backwards
> compatibility.
>
>
>
> That said, I caution us against thinking about this problem only in terms
> of a single use-case or protocol (TLS in this case).  I want to keep this
> discussion considering certificate use-cases that don’t have algorithm
> negotiation mechanisms, for example code-signing, S/MIME, PKI smart cards,
> file encryption, whatever uses certificates in a way that isn’t “online”.
> I would love to see the IETF provide a solution that applies to
> certificates and signatures in general, rather than punting this problem to
> each protocol design team to solve independently.
>
>
>
>
>
> 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.
>
>
>
> This conclusion – that you’re only getting security value once a PQ
> exists, and any alg implementation we chose today will likely be obsolete
> by then -- is probably right for browsers, but what about IoT devices
> validating their firmware signature on boot? Or PKI smartcards?  Or legal
> contracts signed under eIDAS?  Today we are creating certificates and
> signed data objects that will outlive the advent of a QC.  I think that
> blurs closer to the “retrospective attack” scenario that you used for
> motivating composite key exchange.
>
>
>
> While I’m aware that I’m using motivating examples from outside the IETF,
> I think we have an opportunity to define a standard that is generic for all
> (or at least most) certificate use-cases.  Let’s do the debate here about
> carrying multiple signatures and the semantics of validating it, rather
> than pushing it out to each protocol design team to debate independently.
>
>
>
>
>
> ---
>
> *Mike* Ounsworth *|* Office: +1 (613) 270-2873
>
>
>
> *From:* Secdispatch <secdispatch-bounces@ietf.org> *On Behalf Of *Eric
> Rescorla
> *Sent:* January 2, 2020 2:11 PM
> *To:* Carrick Bartle <cbartle891@icloud.com>
> *Cc:* Dr. Pala <madwolf@openca.org>rg>; Salz, Rich <rsalz@akamai.com>om>; IETF
> SecDispatch <secdispatch@ietf.org>rg>; Stephen Farrell <
> stephen.farrell@cs.tcd.ie>
> *Subject:* [EXTERNAL]Re: [Secdispatch] Clarification Question for the
> Comment from Eric Rescorla (
>
>
>
> *WARNING:* This email originated outside of Entrust Datacard.
> *DO NOT CLICK* links or attachments unless you trust the sender and know
> the content is safe.
> ------------------------------
>
>
>
>
>
> 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
>
>
>
>