RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation
draft-ietf-sidrops-rpki-tree-validation-03

I am happy that this document exists.  Documenting how the RIPE validator works is important and valuable.  I think that the content (maybe after getting feedback from the WG) would have been more appropriate as an Independent Submission...or even as simply documentation in the RIPE site.

There is one point that bothers me -- as part of the answer to 'why are we publishing this document?' (paraphrasing from the GenArt review), one of the authors mentioned that "the implementation will change (in fact v3 is just (about to be) released), and then the RFC is outdated." [1]  There is documentation about the rpki-validator-3 in the github repository [2] already -- I haven't taken the time to examine the differences, but the point about the short term value of this document makes me think about the value of publishing it as an RFC at all.

I have also noticed the comments from the WG about the value of this document to implementors, both experienced and new.  I am then balloting 'No Objection'.

[1] https://mailarchive.ietf.org/arch/msg/ietf/pJzebXqz1mtdGAsFi2V3e-G_SYI
[2] https://github.com/RIPE-NCC/rpki-validator-3/wiki

Thank you for the clear description of the purpose of the document in section 1.

This document is Informational, so I will make my comments non-blocking,
but I think that the security considerations could be improved.  It
currently does a good job talking about cases where the procedure can
receive inconsistent inputs (and how it behaves in the face of those
inputs), as well as some other considerations, and this is great!  I think
that the discussion could be more powerful if it also considered how those
inconsistent inputs could be produced, in particular which capabilities an
attacker could have.  There seem to be roughly three classes of actors for
active attacks -- an attacker in the network could modify the transferred
content (including number of files and directory layout) over unecrypteed
rsync or http, an attacker that compromises the webserver's certificate
(or obtains a fraudulent one) could do the same over encrypted https, and
an attacker that compromises the TA signing key could produce
fake-but-"valid" manifests, CRLs, etc..  (Is there more that could be done
with a compromised non-TA CA?  The potential hazards to this algorithm
don't seem to be noticably distinct, though.)  Some consumers may be
willing to trust in the TA's integrity or even the Web PKI and not worry
about those risks.  Though there is always risk of accidental error, of
course, and the current coverage in this document seems adequate for that
risk.

Some additional section-by-section comments follow.

Section 3.1

The key properties needed of cryptographic hash functions are either
"collision resistance" or "second preimage resistance", depending on
whether the attacker gets to pick both hash inputs (the first case) or only
one of them (the second).  Which one is needed here would probably depend
on whether the CA/issuer is trusted to not be an attacker or not, but
regardless, please use the more detailed terminology.

Section 3.2

   [...], or use all objects whose AKI extension
   matches the Subject Key Identifier (SKI) extension (Section 4.2.1 of
   [RFC5280]) of a CA certificate.

"all objects" as discovered within what scope?

Section 4.2

Please expand SIA on first usage.

In bullet point 1, it might help the uninitiated reader to say something
after "and pass it to the object fetcher" to note that "the fetcher will
then fetch all objects available from that repository".

In bullet point 3, please be more clear about which manifest is "this
manifest object" that is used to continue validation processing.

   4.  Perform manifest entries discovery and validation as described in
       Section 4.2.2.

nit: "manifest entry discovery" (singular "entry")

       (Note that this implementation uses the operator configuration to
       decide which algorithm to use for path validation.  It applies
       selected algorithm to all resource certificates, rather than

nit: "the selected algorithm"

Please expand ROA on first usage.

Section 5.1.1, 5.1.2

The syntactic verification performed here is done on what should be
considered "untrusted input", which means that the verification code needs
to be written in a robust manner.  (Given the historical recurrences of,
e.g., ASN.1 decoder security vulnerabilities, we probably need to
explicitly state this in the security considerations.)


Section 9.1

If I understand correctly, RFC 6485 allows for (and predicts the need for)
hash agility in the file hash algorithm.  In this case, it would probably
be appropriate to say something about how "the security of the system as a
whole is limited to that of the weakest hash function allowed by consumers,
but the hash agility provided for by RFC 6485 allows new (stronger) hashes
to be introduced and old hash functions phased out before they are
critically broken".

Section 9.2

   In case of a mismatch described above this implementation will not
   exclude an object from further validation merely because it's actual

nit: "its" (no apostrophe)

Section 9.3

nit: Which behavior is allowed-but-not-required -- a CA signing things not
listed in the manifest, or an RP ignoring things not listed in the
manifest?  I suggest "This RP behavior is allowed [...]".

Section 9.4

This kind of behavior would be seen as an unacceptable vulnerability in a
standards-track protocol, though since this document is only informational
it does not block publication.

Section 9.5

It might be useful to reference Section 5.1.1 and how we sometimes fetch
the entire repository contents, not limited by a manifest listing.