Re: [openpgp] v5 in the crypto-refresh draft

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 07 June 2021 14:01 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE033A1776 for <openpgp@ietfa.amsl.com>; Mon, 7 Jun 2021 07:01:28 -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=GECb1M8f; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=pBc9iEvq
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 78ygnAxvufae for <openpgp@ietfa.amsl.com>; Mon, 7 Jun 2021 07:01:23 -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 6A84B3A177A for <openpgp@ietf.org>; Mon, 7 Jun 2021 07:01:23 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1623074481; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=VwT1JYg4rD+EoPb9pSbRQ+m/SGZ0o1CpISe5w3jl2gQ=; b=GECb1M8fGI2GRpMjYkSfldzCSNCCwiZN7nyY1lX4L5AIfGgeSj+gEbfGroM6LGV4sMBc4 zs/remUsQCIkpcsAQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1623074481; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=VwT1JYg4rD+EoPb9pSbRQ+m/SGZ0o1CpISe5w3jl2gQ=; b=pBc9iEvqY6jQUj99E/1zMDmyEviYyUtL5S+8Kyjc+ePURipruvnRIPK/BxdMYA7jBoWnK PwpAXpXFZMuDL9zfYOvO+7juexJBibAtWChBaimKTwpJ6GVMU0jtoTdb9uWyU7c/DMjED4j Hyu6NiZJGAJBAKeRiFFgP+RE6IElFDXPM4DWre107oUwNm5LTKJjYOb+BPOL53PTiiplhH8 MXnNsIaase7kG7GwsOFUpkG81s8/UQhyNilSeemJh61Nv9rSNxuS/U85CV7AG1JVZPxC380 33PCRGNacv+tqx4vlFqlrPoUKU+wb4x6pz4Lv+2eYwfWjyOlM+Qchl1bIGvA==
Received: from fifthhorseman.net (ip68-0-212-178.ri.ri.cox.net [68.0.212.178]) (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 6EF55F9A6 for <openpgp@ietf.org>; Mon, 7 Jun 2021 10:01:21 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 004FE2049A; Mon, 7 Jun 2021 09:46:23 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: openpgp@ietf.org
In-Reply-To: <YL4HA3rtb1UrKnV8@straylight.m.ringlet.net>
References: <87lf7q6sh0.fsf@fifthhorseman.net> <2e2495e8-6f4c-f842-3886-61cd696a6483@gmail.com> <YL3zYBwALUh8oEed@straylight.m.ringlet.net> <SY4PR01MB6251662F63A66E10F08F6588EE389@SY4PR01MB6251.ausprd01.prod.outlook.com> <YL4HA3rtb1UrKnV8@straylight.m.ringlet.net>
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: Mon, 07 Jun 2021 09:46:20 -0400
Message-ID: <87eeddrdn7.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/openpgp/v5fn_OCh-WKpTWVF90o293-vdkw>
Subject: Re: [openpgp] v5 in the crypto-refresh draft
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jun 2021 14:01:29 -0000

On Mon 2021-06-07 14:46:11 +0300, Peter Pentchev wrote:
> On Mon, Jun 07, 2021 at 11:33:54AM +0000, Peter Gutmann wrote:
>> Peter Pentchev <roam@ringlet.net> writes:
>> 
>> >Obviously not speaking for any of the people who actually work on this, but
>> >you need to keep in mind that the time field is defined as an *unsigned* 32-
>> >bit number, so we'll have another 68 years after the year 2038 to take care
>> >of that.
>> 
>> Except that time_t is signed so it's going to cause breakage if you just
>> assign a 32-bit OpenPGP time to a 32-bit time_t.  Making it 64 bits would both
>> prevent this and signal to 32-bit time_t users that they need to take special
>> care with time values.
>
> Well, if any implementation still uses a signed 32-bit time_t C type in
> the year 2038, it will not be able to do anything anyway. ICBW, but is
> the point of the standard not to define the wire format, and not
> implementation-specific details? An unsigned 32-bit value for the wire
> format should be fine for this century.

The standard is good until 2106, barring implementation failures like
what you describe.

I've opened
https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/issues/55
to suggest some possible tests that would try to identify such
implementation failures.

> But maybe I'll just shut up and let the people who have already
> discussed modifications to the standard (like you, so yeah, sorry)
> say whether anybody has ever raised this before and whether it has been
> discussed.

this came up back in 2016 here:

    https://mailarchive.ietf.org/arch/msg/openpgp/cb32QpGl5-PP02s_dYsTkl3rVK0/

At that time, there was no clear consensus, and (different) reasonable
people advocated for:

 - leaving the timestamps in the standard untouched
 - using a 40-bit timestamp (measured in seconds since the epoch)
 - using a signed 64-bit timestamp (measured in seconds since the epoch)
 - using a signed 64-bit timestamp (measured in 100ns units since the epoch)
 - using ISO 8601 timestamp representations

I'd prefer to not focus on that question right now: aside from not
having consensus, i'd argue it's outside the scope of our current
charter, which is for cryptographic refresh, and we're behind on getting
the crypto refresh done.

    --dkg