[Sidrops] Benjamin Kaduk's Discuss on draft-ietf-sidrops-6486bis-09: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sidrops-6486bis-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

It looks like we may have a setup where a compliant RP and compliant
CA/repository fail to interoperate.  This is sufficiently surprising that
I want to confirm that it's the intended behavior.  In particular, both
manifests and CRLs have thisUpdate and nextUpdate fields, and since
issuing an update to one requires issuing an update to the other (though
the CRL is always actually generated first), it is only natural for us to
give guidance that the times in question should match between manifest and
corresponding CRL.  However, we do this only as RECOMMENDED/SHOULD-level
guidance, and accompany it by guidance to RPs that they SHOULD NOT reject
a manifest of the fields do not match the CRL.  Accordingly, when a CA
violates the first SHOULD and issues manifeset+CRL with mismatched
thisUpdate/nextUpdate, and an RP violates the second SHOULD (NOT) and
rejects such a setup, the RP will be unable to get any RPKI data for that
CA.  (As a tangent, we also have one place where we give related guidance
that the validity period of the single-use EE cert that signs the manifest
match the thisUpdate/nextUpdate period, which we might want to keep in
mind if we make any changes in this space.)

It looks like RFC 6486 had a conditional MUST-level requirement that *if* a
manifest encompasses a CRL, then the "nextUpdate" fields MUST match (no
guidance on thisUpdate), which we change to a statement of fact that each
manifest does encompass a CRL and guidance that the "nextUpdate"s SHOULD
match.
Additionally, RFC 6486 had a MUST-level requirement for the validity
period of the EE cert to exactly match the thisUpdate/nextUpdate time
interval of the manifest, which we currently are relaxing to a SHOULD.

Often in this scenario we would strengthen one of the SHOULDs to be a
MUST so that interoperability is guaranteed, but I'm not sure that I see a
clear argument for which requirement is better to make the MUST.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

My reading of the changes in the diff from RFC 6486 indicate that there is
something of a fundamental shift in the processing model being made, but
this does not seem to be mentioned specifically in the list of changes in
Appendix B (or the introduction/abstract).  Specifically, it seems that
the old RFC 6486 model involved the manifest being a tool that's useful
for the RP and SHOULD be used, but that ultimately the RP policy decides
which signed objects from the repository to use and fundamentally places
trust in the signatures on those objects; the new model in this draft
seems to place the manifest as the primary control on what signed objects
to use, with phrasing like "MUST use the current manifest"/"files not
listed on the manifest MUST NOT be used" and the error-handling behavior
in §6.6 being to fall back to the previous cached state (at a SHOULD-level
requirement), which as I understand it would mean using the previous
cached manifest.  (Maybe I'm wrong about that last bit.) While the new
focus doesn't seem problematic per se, and it's perfectly reasonable from
a process perspective to make that sort of behavior change in a Proposed
Standard, it seems that if this was a deliberate decision it ought to be
emphasized a bit more.  The final bullet point in the change list of
removing the notion of "local policy" is perhaps related to this
fundamental shift, but seems to only cover part of the shift.

Section 3

   The CA MUST sign only one manifest with each generated private key,
   and MUST generate a new key pair for each new version of the
   manifest.  This form of use of the associated EE certificate is
   termed a "one-time-use" EE certificate [RFC6487]

Not really a comment on *this* document (6486bis), but since RFC 6487
generically defines the "sequential use" EE certificate that we are
disallowing for RPKI Manifest use, it seems reasonable to ask whether the
issues that cause us to forbid sequential use in this context might also
apply to other scenarios where "sequential use" certificates might have
been used.  (I did not make a survey of the RPKI specification corpus to
investigate whether such scenarios are likely to exist.)

Section 4.2.1

   fileHashAlg:
      This field contains the OID of the hash algorithm used to hash the
      files that the authority has placed into the repository.  The hash
      algorithm used MUST conform to the RPKI Algorithms and Key Size
      Profile specification [RFC6485].

RFC 6485 has been obsoleted by RFC 7935.

Section 5.1

   2.  Issue an EE certificate for this key pair.  The CA MUST revoke
       the EE certificate used for the manifest being replaced.

Do the mechanics of revocation still need to be undertaken even if the EE
certificate in question has expired?

Section 6.x

The old RFC 6486 procedures allowed ("MAY") the RP to verify that each
file at a publication point is listed in exactly one current manifest,
which is no longer allowed.  I think I can see how this was a problematic
thing to try, but want to confirm that it is intentionally removed.

Similarly, RFC 6486 wanted a warning produced if there were objects
present in the repository that are not listed in any manifest, which does
not seem particularly useful and I do not mind seeing removed.

RFC 6486 also wanted a warning issued if a publication point contained
both valid and invalid manifests; removing that guidance seems correct to
me.

Section 6.3

The two "proceed to Section 6.4"s seem redundant (I suggest removing the
last one).

Section 6.5

   the publication point.  If the computed hash value of a file listed
   on the manifest does not match the hash value contained in the
   manifest, then the fetch has failed and the RP MUST proceed to
   Section 6.6; otherwise proceed to Section 6.6.

This looks an awful lot like "if X; goto Y; else; goto Y", which could
just be written as "goto Y".  However, since §6.6 is the "failed fetches"
processing, in the successful verification case perhaps we don't want to
do that and should instead proceed to use the content of the files listed
in the manifest.

Section 8

Perhaps it is sufficiently obvious so as to go without saying, but I trust
that in a prolonged period of failed fetches, the human operator is
expected to go figure out (via out of band channels) what's up with the
CA/repository in question and whether an attack is underway.

                             The requirement for every repository
   publication point to contain at least one manifest allows an RP to
   determine if the manifest itself has been occluded from view.  [...]

Do we want to say anything about how these properties change during a CA
key rollover or if multiple "unrelated" CAs are publishing at the same
publication point (the latter of which would be quite unusual, if I
understand correctly)?

Section 9

I see that the latest update from IANA has the registry (entry) references
being updated from RFC 6488 to [this document], which is great and
obviates what I would otherwise have remarked upon.

Section 11.1

Now that we're obsoleting RFC 6486, that should probably bump it off into
the Informative References section.

RFCs 6482, 6493, 8209, and 8488 appear to not actually be referenced
from anywhere and thus could probably be removed.

Section 11.2

Do we really want to reference RFC 3370 ("CMS Algorithms") for "the CMS
wrapper of the object" rather than something like RFC 5652 ("CMS")?