Re: [Sidrops] mft/ee validity time window alignment issue - Re: I-D Action: draft-ietf-sidrops-6486bis-05.txt

Job Snijders <job@fastly.com> Sat, 10 July 2021 17:40 UTC

Return-Path: <job@fastly.com>
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 05C113A0D0D for <sidrops@ietfa.amsl.com>; Sat, 10 Jul 2021 10:40:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 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, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 2kp0EW_K5p7G for <sidrops@ietfa.amsl.com>; Sat, 10 Jul 2021 10:40:18 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 8E5183A0D08 for <sidrops@ietf.org>; Sat, 10 Jul 2021 10:40:18 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id bg14so23167769ejb.9 for <sidrops@ietf.org>; Sat, 10 Jul 2021 10:40:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=oPOob2dYbeyWnL7/2htgki5fAbnRf7cou2M8q9Naqvk=; b=isOXAvW4RzN4n/Bp3PemLJmBtiC9i8ObEmUOTpeFLdRr2tdvxDbbFSwxibcyhmTcf1 SETsXzMRzNUcwOlG/2gFe8KKO+q/npInB8RTdYK2cHIR7An5KOn03JaohkrgLcg1QvL0 AIDlrIuWMRhidTxZibu3BrJm6TfBla+dXBIQw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=oPOob2dYbeyWnL7/2htgki5fAbnRf7cou2M8q9Naqvk=; b=DRISEumjb4rHV/k+LfRC196oQWeuA3oDUDSdnuYEOM7WPmiz6ruWPgTy27nkv6+Td6 yp3AlVsC9jF00WK7Bnq/T3+jDU3Kjrb+QgbbRkDmjpQmX2+PDUpIXrmG9dBKMjF6j3Sq wwzsPpHZ0CGyIYDxAOm/I64PU8DNqqhdmj9plAa4tmYLT+ctGbnCUBTYUEwXUIL6i9QQ m7hCyH0BQSP3pZvW+fkrTgx432sYfciVhM/5MPaksRBOr6obkWOpoJn8wVjd/JBx6je7 PldgOwcP8GQF6gIcYfsjSYfqceiTdfCM56rrv2wk5aB88eVfFhdHH3bXp+89FQyUUVWG itAw==
X-Gm-Message-State: AOAM533dW24FsjOrkVbkf49RHK0wNMsBb/+yWHk0uli+h78DNeAtvbk6 QcrM5GoqmaOIR/rozsUKLBlc6g==
X-Google-Smtp-Source: ABdhPJz0O95Qv2eu5f0CtdSgqEHvJb4GihAuW9khd6a5QJOkE0TM/p61sJqzGgOsOHltffBqnoL4Tg==
X-Received: by 2002:a17:906:fc6:: with SMTP id c6mr43846579ejk.65.1625938815101; Sat, 10 Jul 2021 10:40:15 -0700 (PDT)
Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id e2sm4017040ejt.113.2021.07.10.10.40.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 10 Jul 2021 10:40:14 -0700 (PDT)
Date: Sat, 10 Jul 2021 19:39:42 +0200
From: Job Snijders <job@fastly.com>
To: Russ Housley <housley@vigilsec.com>
Cc: Stephen Kent <stkent@verizon.net>, sidrops@ietf.org
Message-ID: <YOnbXkkQf/17ehLh@snel>
References: <162574988984.26098.17271669200254285008@ietfa.amsl.com> <YOc/X/fqp5RepPQD@snel> <3077EE58-C035-4A0D-91C7-AB44B33025D1@nlnetlabs.nl> <564f0d8f-942e-e4e6-b97c-563564f235fe@verizon.net> <YOjHFVZFtCahcfr7@snel> <441FBB61-FE67-4DAF-88A6-7247CF63FDB5@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <441FBB61-FE67-4DAF-88A6-7247CF63FDB5@vigilsec.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/hlfv4wNFYPSAKGSBpFiQunacQ94>
Subject: Re: [Sidrops] mft/ee validity time window alignment issue - Re: I-D Action: draft-ietf-sidrops-6486bis-05.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 10 Jul 2021 17:40:23 -0000

On Sat, Jul 10, 2021 at 12:01:32PM -0400, Russ Housley wrote:
> > If the objective only is to reduce CRL growth, the paragraph must be
> > written in a way that makes it clear it only applies to certificate
> > issuers, and is for their own benefit. 
> > 
> > I propose this text for Section 4.2.1 second paragraph:
> > 
> > """
> >   When signing a manifest, it is RECOMMENDED to use an "one-time-use"
> >   keypair. The EE certificate SHOULD have a validity period that
> >   coincides with the interval from thisUpdate to nextUpdate in the
> >   manifest, to prevent needless growth of the CA's CRL.
> > """
> 
> Job:
> 
> The point of the version field is to help know what to do when you
> stumble.

Who is it helping know and in what way? I'm not sure what to make of
your point. Perhaps I lack understanding.

A deployed RP unaware of 'draft-ietf-sidrops-6486bis-version', will when
validating a MFT object in which the 'version' field exists and is set
to 1, consider the manifest malformed (because RFC 6486 4.2.1 'MUST be 0').
It'll log an error along the lines of "object invalid: invalid version".
RFC 6486 4.4 again repeats "MUST check version of the rpkiManifest is 0"

In practise this means the error condition is detected by counting the
number of elements in the Manifest SEQUENCE, because according to X.690,
section 11.5: "The encoding of a set value or a sequence value shall not
include an encoding for any component value which is equal to its
default value."

The deployed unaware RP cannot recover this situation, it has to
consider the publication point 'distrusted' The RP is not aware that new
RFC specifications exist which define the version field and redefine
some of the rules related to the object profile, the RP expects only 1
Manifest per Publication Point (because thats what then-current specs
specified)

The CAs cannot know how many deployed unaware RPs are out there.

To make the dialogue more generic: in the case of the ROA or GBR
profile, the existence of a new version of the ROA object profile likely
can be managed to some degree. CAs could publish the two profiles next
to each other as separate objects on a Manifest for a period of time. In
such a situation older RPs would will ignore (error) on the newer
version objects, and new RPs will know how to deal with the situation.
Still a tricky migration strategy because dual-publishing in the same
PKI tree is not efficient.

Migrating to new codepoints always is challenging, especially when there
is no ability to perform any form of negotiation between CA and RP.
(unless a new accessDescription element for the id-ad-rpkiManifest
accessMethod is introduced towards a repo with newly formatted objects).

Kind regards,

Job