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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 25 March 2021 00:54 UTC

Return-Path: <dkg@fifthhorseman.net>
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 D6D2B3A1484 for <spasm@ietfa.amsl.com>; Wed, 24 Mar 2021 17:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=ySrDVhbf; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=1iZiFtMX
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 15LaiB-Djoyj for <spasm@ietfa.amsl.com>; Wed, 24 Mar 2021 17:54:54 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52393A147F for <spasm@ietf.org>; Wed, 24 Mar 2021 17:54:54 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1616633693; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=2zZzgbLrFilm48Q7vCAVFtCfM01Y8j06xus9pIdtGAY=; b=ySrDVhbf9mBdbKmxU2QUMSKuWCDHfLabNxZvM4oY7z57/weU1jxU/FSByYhT2OUtxeCqR KxAMGy/v2J4icfiDw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1616633693; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=2zZzgbLrFilm48Q7vCAVFtCfM01Y8j06xus9pIdtGAY=; b=1iZiFtMXt5Y22JP7v7yvGA55hxOVz0IDR9WYxS6XRHAL4patFP5QQHB9sk2dw+x2agwNT yqV2Qy/CytfGLtzUarlGaN45pUkGG9XiGW1XbY9me4tGAmcXCPuCD4JQEo27h5hFsgcbCe4 hqvHYh52PKo5P5VLwGSX3woWOjwTObQBLCdQMGlyCpDdSE/67LEF0pvKd1AjBnrphC+n6to O+K9x0LYw1tt1ZR8XX/HMSvRk8G3psQ9DobHWd35p4zhmTTd0DgcKuHiPqoPk7ERVXLC1d0 pLRRtmYAKAlUwn7+nwNS4VQ3TWgtUlGvF381FVlb38CDenEib9a0fGs/Vu4A==
Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:841d:2bce:26c3:59c6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id D1A4BF9A6; Wed, 24 Mar 2021 20:54:52 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 4225720436; Wed, 24 Mar 2021 17:38:28 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>, Russ Housley <housley@vigilsec.com>, Rene Struik <rstruik.ext@gmail.com>, LAMPS <spasm@ietf.org>
In-Reply-To: <31577.1616604808@localhost>
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>
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Wed, 24 Mar 2021 17:38:27 -0400
Message-ID: <87k0pw2pws.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/QHDBMX13fVnLoKLXGHR7dUjmvFc>
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 00:55:00 -0000

On Wed 2021-03-24 12:53:28 -0400, Michael Richardson 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.

The scenario I think you're describing does seem like it might be
potentially useful, but only in the context of defending against a very
specific kind of attack, with very specific protocol expectations.

In particular, if we learn of a quantum-based cryptanalytic attack that
weakens an existing signature system by allowing the production of a
signature (with some remaining non-negligible workfactor), but *without*
permitting private key recovery from public key material, then:

 - the legacy scheme could still be useful in contexts where "freshness"
   of signatures can be detected. For example, in a time-bounded
   challenge-response protocol (verifier sends signer a challenge,
   signer produces signature over a message that includes that challenge
   in a predetermined way), or a key-agreement protocol (e.g. in modern
   TLS) where both parties contribute to the underlying ephemeral
   established secret, and then one or both parties sign the secret to
   prove identity to the other.

I don't know enough about the field of possible quantum attacks to know
whether this latter situation is a plausible scenario.  Certainly if the
quantum attack permits private key recovery from public key material,
then the time bounds described above are meaningless, beceause the
private key could be derived offline, in advance of the protocol
exchange, and then the private key could be used directly with no
additional delay.

        --dkg