Re: [Sidrops] I-D Action: draft-ietf-sidrops-cms-signing-time-03.txt

Ties de Kock <tdekock@ripe.net> Fri, 19 January 2024 11:26 UTC

Return-Path: <tdekock@ripe.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3BBC14F5FC for <sidrops@ietfa.amsl.com>; Fri, 19 Jan 2024 03:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dK-3EPcXHRF0 for <sidrops@ietfa.amsl.com>; Fri, 19 Jan 2024 03:26:10 -0800 (PST)
Received: from mail-mx-2.ripe.net (mail-mx-2.ripe.net [IPv6:2001:67c:2e8:11::c100:1312]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C13C14F696 for <sidrops@ietf.org>; Fri, 19 Jan 2024 03:26:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=rp1h5Obp6/S9sH+EMvFPWItnjgrANn/AELDXIUcRDRQ=; b=mZ891g5Wj3GnNTfBYsxccchN MpncVpqyUfPejb52hGz4wscqCZEW4N262dufdXDUW4D7KnWNBMnmt3kIO1A9UFgQJ0HM+e+ldg1/A N5WX8cgC+7bDyc+8BIcMai6xkuhkWECM7195saTBaj9u80t1DaDOjOjAP6Ydt1nm7QcyDifAi5eDm a5gzIKfsgV+oO32X+R8szKGWW9HKjZHYfPdBmpwgPVKgFPLJP1XR8nmm6m3yk+5Fz85OqIdm6B9tI rHXixOcQiGxbEqZ+6ZNev/gZ0NW8RISX5n+ZXx8gENj1g9JlBi3Q+ivMc3r9jDdXfQlvyj/q5x0Q6 t9tW2pePag==;
Received: from imap-01.ripe.net ([2001:67c:2e8:23::c100:170e]:35836) by mail-mx-2.ripe.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from <tdekock@ripe.net>) id 1rQn0h-000T5Y-1Z; Fri, 19 Jan 2024 11:26:07 +0000
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by imap-01.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from <tdekock@ripe.net>) id 1rQn0h-0044Uf-1I; Fri, 19 Jan 2024 11:26:07 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <ZapR2qVBAu7lECFB@snel>
Date: Fri, 19 Jan 2024 12:25:56 +0100
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7547BE09-8FF6-40F4-BC6E-388BAEFE6CD6@ripe.net>
References: <170561454824.54895.360140302624981870@ietfa.amsl.com> <ZamgKc5PTJPDcISD@snel> <C10EC4E3-9A59-4BBA-B5DC-DB4680AD0B0D@ripe.net> <ZapR2qVBAu7lECFB@snel>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e12f0b3b7d7ecacf1cfc280f9cdabcd156
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/hi9lPTDYtbOubF0ZzvxJ1XEr1Cg>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-cms-signing-time-03.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jan 2024 11:26:14 -0000

Hi Job,

> On 19 Jan 2024, at 11:41, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
> 
> On Fri, Jan 19, 2024 at 10:52:58AM +0100, Ties de Kock wrote:
>>> On 18 Jan 2024, at 23:03, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
>>> Another pass was made over the text to improve the structure of the
>>> document and complete the surgery updates to RFC 6488. The
>>> "Implementation Status" section was also updated.
>> 
>> Can you clarify why the document now mandates that binary signing is
>> disallowed?
> 
> The document has consistently contained a proposal to disallow the
> binary signing-time attribute since its very first version, even before
> working group adoption (draft-spaghetti-sidrops-cms-signing-time-00,
> June 2023). The working group adopted that proposal.

I missed it and only this latest diff made it explicit. And this diff raises
more questions because imo the handling is now inconsistent.

>> This has significantimpact on implementations that are fully
>> conforming to rfc6488 and has a significant impact on those
>> implementations, effectively invalidating their test set of objects.
> 
> Indeed, RFC 6488 is updated and simpified. Preventing invalidation of a
> set of private objects which solely exist for regression testing seems a
> non-goal to me? It seems unsurprising to me that a full coverage test
> suite for 6488 objects may need to be updated if 6488 is updated.

I am fine with mandating the existence of signing time. That provides value now
that we have found a goal for that attribute that was unused until last year.

Based on the document, the reason to go further than mandating signing time is
aesthetics imo. In my opinion, based on the document, we lack motivation for
the further changes.

>> It also invalidates objects generated by public CA implementations if
>> a feature is enabled.
> 
> Extensive long-term quantitative research showed that no public
> Certification Authorities issue and publish Signed Object with a CMS
> binary signing-time attribute. The complete absence of the binary
> signing-time attribute in the global RPKI is a positive signal that it
> is feasible to formally disallow the attribute. I suspect that lack of
> support for binary signing-time in commonly used libraries contributed
> to binary signing-time's lackluster fashionability in the field.

I agree that implementations of 6488 have generally skipped the checks mandated
on signing time.

> 
>> Please elaborate on the improvement in security posture this gives iff
>> any.
> 
> There are more angles to consider than just security posture:
> disallowing the binary signing-time attribute simplifies implementations
> on both the signer and the RP side: instead of enumerating, parsing,
> checking for duplicate attributes, and also comparing the encoded
> timestamps against each other for both normal & binary signing-time
> attributes; after publication of this draft RPs merely need to confirm
> the absence of the binary signing-time attribute. To me this seems is a
> welcome simplification.

Now we are getting to the core of what confuses me. My read of the draft is that
binary signing time can still be present, just not in the set of signed
attributes (this would not comply to RFC6019, but implementations have ignored
RFC6019 in general so far). This draft may even introduce malleability this way.

How about:
  * Mandating that the binary signing time attribute MUST NOT be present (signed or unsigned).
    Yes, this is in RFC6019. But we no longer refer to that. And as you said,
    some RPs have not implemented those MUSTs because of a lack of library support.
  * Clarifying in security considerations that the previous profile allowed objects
    to have ambiguous singing time if the implementation was not standard
    compliant and this document prevents objects from having ambiguous signing time?