Re: [lamps] [EXTERNAL] Re: LAMPS Re-charter

Carl Wallace <carl@redhoundsoftware.com> Thu, 25 March 2021 17:19 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DA43A2800 for <spasm@ietfa.amsl.com>; Thu, 25 Mar 2021 10:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 QkWPKhrHqN9o for <spasm@ietfa.amsl.com>; Thu, 25 Mar 2021 10:19:18 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 E50F53A2801 for <spasm@ietf.org>; Thu, 25 Mar 2021 10:19:17 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id i19so2210624qtv.7 for <spasm@ietf.org>; Thu, 25 Mar 2021 10:19:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=Nbl6xUrt6L67p85Zk+RK9K6C/gWA+5K4wK7u+f09Stw=; b=bau3TWIj9ZGGjhbySiiiaMJeX9bJGoay8vjoD3WrJsKuUgUPH6CrJKq/xhQpRm7MT4 0hN3VcQA2P2QFQ5m2mi0PY9qiWp6ZWj3aado2AoEQazQNn63yOauDklK4vmnkUR7lPu1 aQ74CLe5zM3qsCOFLYBuUq6eFPDAnBUWCjVf4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=Nbl6xUrt6L67p85Zk+RK9K6C/gWA+5K4wK7u+f09Stw=; b=alVsdyaijO9RhIHxundDrqFkb4ugYcuj6gxCq0TO1q6veRGRL2zIq5Q/fYxf7DwNzr e4K5qZx9WY3FhjStX2S3Wzmg+FwWYZzRCDPtWin0Wgya1gyInmjOv8QPCN/7qvpM8DZL ksdc/4iZsf50RgA/t/BIf1tbOYx7rLbh/YFvuzoDHDrUuLd8h5CbX3jB1s7cgkTijHkj rA6XlZDm0wIh8edpyjRlFIWRNhh1Kk7hZto4G4x9rTrKnwnUnAIuNF9Nhw8U/HycppBh a3sThEEjcj1ZtbYge9l+gSXdwgiRUGXAS7VRg2IMJotxOwrjduktGlI7dbUmYxSoxYiC eo0A==
X-Gm-Message-State: AOAM533YjRpj0Dij+7MJyNVPtfiLHDce/bBWlsXP1ZS/5+CKdnCK4CIu 7Oj9ARWrbA1Skl+GZwTxcgOs7A==
X-Google-Smtp-Source: ABdhPJyUo1WhrYoAmP85U9ja5OKHsTDdJ7gTUroCYMT9/Vv6hVMbArDPeXaieISjiei+mmzxqnFk4A==
X-Received: by 2002:aed:31e4:: with SMTP id 91mr8818660qth.9.1616692755356; Thu, 25 Mar 2021 10:19:15 -0700 (PDT)
Received: from [192.168.2.16] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id d84sm4658696qke.53.2021.03.25.10.19.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Mar 2021 10:19:14 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.47.21031401
Date: Thu, 25 Mar 2021 13:19:14 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
CC: LAMPS <spasm@ietf.org>, Russ Housley <housley@vigilsec.com>, Rene Struik <rstruik.ext@gmail.com>
Message-ID: <D16B190E-67FD-4801-9034-ACF5AE1EF7D2@redhoundsoftware.com>
Thread-Topic: [lamps] [EXTERNAL] Re: LAMPS Re-charter
References: <5A22DF7B-BCA5-42F6-BB95-D4F70FDB1996@vigilsec.com> <951CAF0F-7461-4057-B95E-D1F6CAE61D02@vigilsec.com> <4c18a9982cc94df2952d7b2cbae89d99@cert.org> <7B82765F-9C7A-4C4D-B115-A2835B44E6D6@vigilsec.com> <b3fdb1ac051b4ae0ad748782daebead2@cert.org> <ACE141CD-B0B7-45D3-B54F-BE25275A0D25@vigilsec.com> <29f2b6c9-d7fe-0aa5-4509-d10279a2d902@gmail.com> <EC04667D-6426-4942-81E8-D0EEDCBFA359@vigilsec.com> <c709e623-80f1-3803-0dae-4785d0028828@gmail.com> <B70F19FF-2042-41F0-881A-FCFB13CFCC87@vigilsec.com> <DM6PR11MB4380EA3E63FDFC161E5DA8689F649@DM6PR11MB4380.namprd11.prod.outlook.com> <874kh150d1.fsf@fifthhorseman.net> <31577.1616604808@localhost> <87k0pw2pws.fsf@fifthhorseman.net> <6832.1616683780@localhost> <DM6PR11MB43808ABD3C5FD4ABFB84A10C9F629@DM6PR11MB4380.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB43808ABD3C5FD4ABFB84A10C9F629@DM6PR11MB4380.namprd11.prod.outlook.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/czR21klwxGMXKaGtU2XG88UbKvc>
Subject: Re: [lamps] [EXTERNAL] Re: LAMPS Re-charter
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2021 17:19:24 -0000

Evidence records (RFC4998) and DSSC policies (RFC5698) got at that kind of thing using timestamps and Merkle trees with maintenance of the evidence record being required before an outgoing algorithm was of no value.

On 3/25/21, 1:12 PM, "Spasm on behalf of Mike Ounsworth" <spasm-bounces@ietf.org on behalf of Mike.Ounsworth=40entrust.com@dmarc.ietf.org> wrote:

    @dkg it sounds a bit like you're hinting at timestamping servers (or their modern equivalent: blockchains and merkle trees).

    I wonder if CT logs have the "time-bounded" property you're looking for: any certs indexed into the CT Merkle tree before the "quantum apocalypse" can still be trusted (the cert itself - DN, SANs, etc - can still be trusted; the keys inside it may well be compromised). Though the things getting CT-logged (public web certs) are only valid for ~ 1 year, so they'd likely be expired by the time you care to look back.

    ---
    Mike Ounsworth

    -----Original Message-----
    From: Spasm <spasm-bounces@ietf.org> On Behalf Of Michael Richardson
    Sent: March 25, 2021 9:50 AM
    To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
    Cc: LAMPS <spasm@ietf.org>; Russ Housley <housley@vigilsec.com>; Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>; Rene Struik <rstruik.ext@gmail.com>
    Subject: Re: [lamps] [EXTERNAL] Re: LAMPS Re-charter


    Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
        >> Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
        >> > PQ-hybrid signatures are a much easier thing to tackle than PQ-hybrid
        >> > encryption.  But PQ-hybrid encryption is also the thing that has the
        >> > most urgency.  Signature verification has an out: verifiers can
        >> > time-bound their acceptance of legacy signatures once a quantum-based
        >> > cryptanalytic attack becomes known to be plausible.
        >>
        >> Do you mean that a verifier can say, "I'll accept your legacy signature as
        >> long as it's less than 2hr old"
        >> ("2hr" being the time I think it takes for a PQ to be mounted).

        > The time-bound i was thinking of was:

        > - If a quantum-based cryptanalytic attack becomes feasible on a given
        > algorithm at time T, then a verifier can still re-validate any
        > signatures that arrived (that is, that the verifier has had a copy
        > of, or that is visible in some robust historic ledger) prior to time
        > T.  That is, old, pre-existing signatures are not automatically
        > invalidated by a new quantum attack.  Note that this is *not* the
        > case for encrypted material -- old, pre-existing encryption
        > protection can indeed be invalidated by a new quantum attack.

    Thank you for the clarification.
    I wasn't proposing something different, just trying to understand.

    You are right that a the PQ attack would likely be used to recover private keys, not just forge signatures.

    --
    Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
               Sandelman Software Works Inc, Ottawa and Worldwide




    _______________________________________________
    Spasm mailing list
    Spasm@ietf.org
    https://www.ietf.org/mailman/listinfo/spasm