[Sidrops] Re: Deb Cooley's No Objection on draft-ietf-sidrops-rpki-ccr-08: (with COMMENT)

[Deb Cooley <[e-mail]>]

Thanks for the speedy reply!!

inline with [DC]

On Mon, Jun 22, 2026 at 4:16 PM Job Snijders <[e-mail]> wrote:

> Dear Deb,
>
> Thank you for taking the time to review this document.
>
> On Mon, Jun 22, 2026 at 11:57:40AM -0700, Deb Cooley via Datatracker wrote:
> > Deb Cooley has entered the following ballot position for
> > draft-ietf-sidrops-rpki-ccr-08: No Objection
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-ccr/
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I would appreciate consideration, most of these can be resolved pretty
> easily.
> >
> > Thanks to Joe Salowey for their secdir review. I agree with Joe's
> assessment:
> >
> >  - The continued use of SHA-1 (Section 3.4.1.1 Subordinates and Section
> 3.4.4):
> >  At some point, a migration will have to happen, because at some point
> >  implementations won't have SHA-1 implemented.  If it doesn't make sense
> to fix
> >  this issue in this draft, I recommend that the risks be mentioned in
> Section 6.
>
> I'm sorry to say but both your and Joe's review appear to fail to
> appreciate the context within which SHA-1 is used here. What risk
> _exactly_ should be mentioned in section 6? It seems too simplistic to
> blindly raise an issue on any and all use of SHA-1.
>

[DC] perhaps I used the wrong word 'risk'.  The real issue is that SHA-1
will not be implemented in the future.  I guess the risk here is that SKI
and AKI can't actually be validated at all in that case.  Again, I agree
that this draft might not be the place, but the working group, and indeed
the community should consider the future if/when SHA-1 is deprecated enough
that it stops being implemented.

>
> What risk is there in the use of SHA-1 in the RPKI certificate profile?
> SHA-1 is not used for cryptographic purposes in the RPKI.
>

 [DC] it isn't crystal clear, except to those that know how X.509
certificates work to know that the SKI and AKI are in fact, hashed and
signed as part of the certificate signature.

>
> I believe that the robustness of the RPKI depends *entirely* on the
> robustness of RSA-2048 and SHA-256. If you have reason to believe
> otherwise please explain.
>

[DC]  this is true, but RSA-2048 won't stand forever.   Again, not an issue
for this draft.

>
> I'll attempt to contextualize the use of SHA-1, my apologies if I'm
> being too verbose.
>
> The 'ManifestInstance' structure contains a 'hash' field, this field
> contains a SHA-256. The state of the art cannot collide SHA-256, right?
>
> Then the next field in the 'ManifestInstance' structure is 'size', I
> think we'll agree that multiple different digital objects could have the
> same file size, and that this is not an issue because the aforementioned
> SHA-256 uniquely identifies the underlaying object? However, it is
> convenient for CCR consumers to know the object size associated with the
> SHA-256.
>
> Now, the _exact_ same thing applies to the 'aki' field (which contains
> a SHA-1). That SHA-1 string appears verbatim in the object referenced
> by the SHA-256 in the 'hash' field. Just like with 'size' field,
> any 'collisions' are not an issue.
>
> Finally, the ManifestState contains a SHA-256 computed over all the
> instances of ManifestInstance. This makes CCR a simple hash tree.
>
[DC] while hash collisions when SHA-256 is used are not feasible, the
attacker can replace the parts they want, and rehash the whole structure.
Hashes don't protect 'integrity' (see below), they do function as a way to
detect non malicious file corruption.


>
> (As an aside: key identifier 'collisions' can in fact happen trivially,
> simply by virtue of multiple RPKI certification authorities using
> the same key pair. Of course, using the same key pair for different
> certificates is not the best practise, but there is no technological way
> to stop anyone from inappropriately using the same RSA-2048 private key
> for multiple different RPKI CAs.)
>

[DC]  indeed, and I might raise an issue for this too (and I did do this
prior to retiring in my day job).

>
> >  - Privacy/sensitive information: The ramifications of the information
> >  not being public should be explained in Section 6 where it is
> >  mentioned in the last para.
>
> I have trouble following the above paragraph.
>

[DC]  The current language is 'RPKI information is normally public'.  What
happens if it isn't public? Or is it 'always public'? Recognizing that the
language isn't 'normative', but sort of reads that way.  Is there a
recommendation if the information isn't public?  Don't include it in the
CCR?

>
> > Section 5.1: Verifying a hash value that isn't signed isn't actually
> > an integrity check, except in the case of unintentional integrity
> > issues. Certainly an attacker can modify both the original data and
> > the hash. Please clarify what type of integrity is required/intended.
>
> Many file formats use a CRC, or stronger hash (such as SHA-256) to help
> detect truncation or other forms of file corruption. The draft notes
> that the provenance of a CCR file is out of scope.
>
> I believe 'integrity' is the right word, here, but it reads like you
> interpret the use of the word 'integrity' as 'authenticity', is that
> correct?
>

[DC]  I do think it would be helpful to say that the concern is
non-malicious corruption.  To me, integrity spans the whole space from
simple bit flips to impersonation.  If it isn't specified, I usually assume
that it is intended to protect against a malicious attacker.

>
> > Section 6, last para: I'm not sure how the fact that CCRs are not
> > signed is related to whether the RPKI information is public (or not).
> > Perhaps two paragraphs are needed? Move the middle sentence out into
> > its own paragraph (since it has nothing to do with signatures or
> > authenticity.
>
> Thank you for the suggestion, I think that indeed helps with the
> readability. I've updated the edit buffer as follows:
>
> https://github.com/job/draft-sidrops-rpki-ccr/commit/66349a3eb73f5a87af20709aedc2d4fe3a5466de


[DC]  that's better, thanks.

>
>
> Kind regards,
>
> Job
>