Subject: Re: [Sidrops] mft version field issue (Was: I-D Action: draft-ietf-sidrops-6486bis-05.txt)

From: Job Snijders <[email-masked]>
Date: Sat, 10 Jul 2021 20:15:46 +0200

(spinning off a new thread)

On Sat, Jul 10, 2021 at 12:01:32PM -0400, Russ Housley wrote:
> 
> The point of the version field is to help know what to do when you
> stumble.

I'm starting to suspect that: RFC 6486 section 4.4

    "MUST check version of the rpkiManifest is 0"

... should've been along the lines of:

    "MUST be set to version 0, and MUST be ignored when validating"

I checked a few RPs and it seems that most RPs will consider a Manifest
invalid if it contains a version field, because of the 4.4 language.

At this point in time the 'version' field in Manifests is not usable as
a transition mechanism towards anything.

If people want to use it, first an RFC should be published detailing how
RPs should treat the 'version' field in the Manifest eContent, after
which in subsequent publications we can start using the 'version' for
some purpose.

Kind regards,

Job

---

From: Stephen Kent <[email-masked]>
Date: Sat, 10 Jul 2021 15:00:47 -0400

Job,
> .. should've been along the lines of:
>

And they would be behaving properly if they did so.

Ignoring the version field would not be consistent with IETF policies 
employed in many, many RFCs.

> a transition mechanism towards anything.
see my reply to your earlier message, which describes how one might 
accomplish such a transition.

Steve

---

From: Russ Housley <[email-masked]>
Date: Sat, 10 Jul 2021 15:43:08 -0400

Job:

If you try to decode, and it fails, then the Version should tell you what ASN.1 module was used by the originator in order to properly decode it.  All of the RPKI-related CMS content types started with a Version of zero.

Russ

> On Jul 10, 2021, at 2:15 PM, Job Snijders <[email-masked]> wrote:
>

---

From: Job Snijders <[email-masked]>
Date: Sat, 10 Jul 2021 21:51:13 +0200

On Sat, Jul 10, 2021 at 02:56:47PM -0400, Stephen Kent wrote:
> In the IETF we usually employ a version number change to facilitate a
> transition to a new format, or to accommodate a change in the rules for
> processing an existing object. If RP software can't deal with a change of
> version number for an object, the RP software is seriously deficient.

If you mean by "RP software can't deal with a change of version" that
the RP crashes (or worse), indeed, I agree, of course.

What I meant with "the RP cannot parse the eContent", is that the RP
applies its validation procedure - expecting the version to 0, and if
the version is not 0 the RP considers the Manifest invalid, and thus all
subordinate products are lost from the RPs view.

A change of version number (going from 0 to 1) will mean RPs will reject
'version 1' manifests upon discovery. In your other message you
acknowledge that Manifests with an unexpected version field (or
unexpected contents) should be considered invalid.

> > Given that CA's in their SIA currently can't point to two different
> > Manifest objects, unless a new accessDescription element for the
> > id-ad-rpkiManifest accessMethod is introduced. At that point CAs would
> > be doubly publishing Manifests (v0 + v1)... all to reduce some potential
> > churn in the CRL space.
> 
> I agree that a CA cannot point to two different manifests at the same time,
> using existing the existing SIA format. However, that does not mean that
> it's impossible to transition to a new manifest format. The CA  key rollover
> procedure, described in RFC 6489 describes a process which would allow a
> phased transition of a new manifest format.

I fail to see how a CA key rollover strategy can be applied to the
situation at hand, to facilitate introducing a new 'version' number in
the eContent.

When a CA 'refreshes' and starts pointing to a newly created manifest
object (version 1), any deployed RP unaware of what 'version 1' means
will discover and subsequently invalidate the Manifest.

To me it seems that 'version' is not backwards compatible for older RPs,
because it was not specified to be backwards compatible.

How can a CA cater to both last year's RPs (which all expect version 0),
and next year's RPs which support both v0 and v1? I fail to see the
migration path.

Kind regards,

Job

ps. to illustrate the point of the decision tree I'm looking at, see
below, all test & branch paths lead to 'goto out', which means the RP
will consider the manifest invalid. The introduction of a 'version 1'
object will cause older RPs to lose sight of the subordinate products.
This is not attractive to CAs, who generally wish to pass validation by
as many RPs as possible.

mft_version = ASN1_INTEGER_get(tt->value.integer);
if (mft_version == 0) {
	warnx("%s: RFC 6486 section 4.2.1 and X.690, 11.5: not"
	    " expecting version field for version 0", p->fn);
	goto out;
} else {
	warnx("%s: RFC 6486 section 4.2.1 unexpected version: "
	    "%ld", p->fn, mft_version);
	goto out;
}

---

From: Job Snijders <[email-masked]>
Date: Sat, 10 Jul 2021 21:57:02 +0200

On Sat, Jul 10, 2021 at 03:43:08PM -0400, Russ Housley wrote:
> If you try to decode, and it fails, then the Version should tell you
> what ASN.1 module was used by the originator in order to properly
> decode it.  All of the RPKI-related CMS content types started with a
> Version of zero.

Yes.

So when a RP decodes it and fails, the expectation is that the RP will
immediately upgrade to a newer version of their RP software?

If a CA jumps to the new version 'too soon', the CA risks losing their
ability to inject VRPs into the routing systems of the RPs.

At what point can a CA know or expect that sufficient RPs in the field
are able to decode their objects if they choose to use the new version?

Kind regards,

Job

---

From: Russ Housley <[email-masked]>
Date: Sun, 11 Jul 2021 09:58:41 -0400

> On Jul 10, 2021, at 3:57 PM, Job Snijders <job=[email-masked]> wrote:
> 

Job:

I do not envision immediate upgrade, but please think about the other case.  Most of the community has upgraded to version N, and a decode fails.  The version tells that this source is still using N-1, so the decode can be retried with the appropriate syntax.

Russ