[Sidrops] Re: [WGLC] draft-ietf-sidrops-rrdp-same-origin-00 - Ends 1/July/2024

[Job Snijders <[e-mail]>]

Dear Alberto,

I'll go through your items one by one.

On Mon, Jun 17, 2024 at 07:40:45PM -0600, Alberto Leiva wrote:
> Tim proposed
> 
> > and possible disallowing the use of get parameters in URIs, seems
> > prudent.
> 
> I understand that this was ultimately agreed against, but I feel the
> RFC should explain why, because the problem explained in section 2
> aggressively invites this solution.

Disallowing HTTP query strings (URL parameters) does not solve the
problem outlined in Section 2, on the other hand, imposing same-origin
policy does solve the problem. In a world where same-origin policy is
imposed, HTTP query strings do not cause problems. I'll elaborate a bit
more because you return to this point later on.

> And Ties mentioned:
> 
> >> This solution means that if the adversary wants to feed large files
> >> into RPs, they have to host the data themselves, and pay for the
> >> network bandwidth cost themselves. This seems reasonable to me.
> >
> > This is a good mitigation and we should make sure that this line of
> > reasoning is captured somewhere.
> 
> As far as I can tell, the draft does not capture this reasoning.

Section 5 already states "cross-origin requests allow one repository
operator to increase resource consumption for another repository
operator". Logically, following imposition of same-origin policy,
operators will bear their own cost, because all data will be on the same
origin. Spelling this out any further might offend the reader. :-)

> ------------------------------
> 
> > RPs cannot avoid scheduling a new download per Section 3.4.1 of
> > [RFC8182] because Delta file, Snapshot file, session_id and serial
> > are significant only in scope of the referring SIA AccessDescription.
> > In other words, SIAs are globally unique and can be deduplicated
> > before scheduling fetches, but RRDP session_ids are not globally
> > unique, contrary to what Section 3.1 of [RFC8182] suggests.
> 
> I still have some beef with this paragraph. I imagine part of this is
> just my lack of creativity, and I apologize for that, but I would
> prefer if the RFC's reasoning didn't leave holes for the reader to
> fill.
> 
> 1. Why "Delta *file*" and "Snapshot *file*"?
> 
> If an RP wants an index to prevent a file redownload... wouldn't using
> the *file* itself as an index defeat the entire purpose?
> 
> Don't you mean "Delta URL" and "Snapshot URL"?

RFC 8182 uses the phrases "Delta File" and "Snapshot File", in
draft-ietf-sidrops-rrdp-same-origin I followed that way of describing
things for consistency.

> 2. The tissue that connects this paragraph to the surrounding ones is
> camouflaged by the SIA detour, which doesn't seem very relevant to me,
> and raises a question.
> 
> I feel like the document should elaborate on "SIAs are globally unique
> and can be deduplicated before scheduling fetches" at some point. The
> sentence sounds incorrect without context, and the entire paragraph
> seems to orbit around it.
> 
> What is enforcing SIAs to be globally unique? Suppose:
> 
> - Certificate A has rpkiNotify SIA "https://example.com/a/notif.xml"
> - Certificate B (elsewhere in the tree, or even in another tree) has
> rpkiNotify SIA "https://example.com/a/notif.xml?a=b"
> 
> Given that the draft seems reluctant to advocate for parameter
> removal... how do you deduplicate those?

You don't! :-)

The two examples you offer are distinct URIs pointing to *potentially*
distinct resources (in this context, Update Notification Files).

It is entirely possible that a future repository operator uses HTTP
query parameters to separate enterprises from each other. There is no
technical reason to disallow this. Our job here is not to dismember HTTP
into something no HTTP client can recognize.

In your example, the first portion of the path '/a' could be an
executable module or program, that interprets '/notif.xml' and
'/notif.xml?a=b' as distinct arguments.

> 3. I'm not actually sure if we understand the same concept from the
> word "deduplicate," because it's not defined in the draft, and it's
> also not defined in any of the RFCs it references. (I didn't search
> deeper, though.)

Let's take an example from LACNIC:

TA [1] rpkiNotify in the SIA points to https://rrdp.lacnic.net/rrdp/notification.xml
Another [2] CA cert's rpkiNotify in the SIA points to
https://rrdp.lacnic.net/rrdp/notification.xml

[1]: https://console.rpki-client.org/ta/lacnic/rta-lacnic-rpki.cer.html
[2]: https://console.rpki-client.org/repository.lacnic.net/rpki/lacnic/946DAE8464E7C581E9BA5787F74CBDA9DCF6F8CD.cer.html

Clearly, https://rrdp.lacnic.net/rrdp/notification.xml equals
https://rrdp.lacnic.net/rrdp/notification.xml and the RP can
'deduplicat'e in the sense that it does not need to maintain a RRDP
session per certificate per rpkiNotify.

The rpkiNotify's in the SIA are globally unique because URLs are used. A
URL (Uniform Resource Locator) is the address of a unique resource on
the Internet. The globally unique assertion banks on everyone using the
same root servers, which seems reasonable in this context.

> 4. Isn't there a "the" missing between "in" and "scope"?

I don't think so, but if it is, the RFC editor will fix it. My English
still needs work, so don't take my word for it.

> 5. The "in other words" second half of the paragraph doesn't seem
> equivalent to the first, adding more confusion.

Would it help if I change "SIAs" to "rpkiNotify accessLocations"  or
something along those lines?

Perhaps:

"""
URIs in the rpkiNotify SIA AccessDescription extension are globally
unique locators so when different CA resource certificates contain a
pointer to the same rpkiNotify URI, the RP need only download it once.
On the other hand, RRDP session_ids are not globally unique, contrary to
what <xref target="RFC8182" section="3.1"/> suggests.
"""

> It's not equivalent because it only elaborates on session_id, leaving
> "Snapshot file," "Delta file" and serial in limbo. Furthermore, the
> logic that explains why session_id is not indexable doesn't seem to
> extend to the other fields.

Section 3.1 of RFC 8182 explicitly states that session_id's are globally
unique, and they simply are not. Keep in mind that Snapshot File, Delta
File, serial, session_id and the hash attributes are all under control
of the publication point operator, not the issuing CA (although the
issuing CA choose to include a particular rpkiNotify).

> --------------------
> 
> Maybe I should propose an alternate version of the paragraph:
> 
> > RPs cannot recognize they have already downloaded the file, because
> > the attacker has effectively morphed the Snapshot's URL into a
> > different Uniform Resource Identifier [URI], and nothing enforces
> > session_id (and/or serial) to be globally unique (despite what Section
> > 3.1 of [RFC8182] suggests).

I appreciate suggestions for alternative text, but I find the
alternative somewhat hard to read. I think you are close though, for
example: it is only after the file has been downloaded that the RP can
calculate whether the hash matched with what was listed in the UNF.

> And then maybe explain the SIA quirk in a separate paragraph:
> 
> > This is all in contrast to the SIA AccessDescription field, which
> > doesn't suffer this problem because [...].

because ... we favour CA intent?

> ---------------------------
> 
> > If the adversary increments the serial in tandem with RIPE NCC
> > incrementing their RRDP serial, every next request to
> > _https://badhost/notification.xml_ causes another large file download
> > on the RIPE NCC servers, exacerbating the issue.
> 
> Aaaaaaah. I don't like this paragraph either.

I'm happy to remove section 2 in its entirety if it is causing you
heartburn.

The goal of this draft proposal is just to impose new requirements
(section 3.1 and 3.2). For me it is a non-goal to explain how RRDP works
or how to implement it sanely beyond SOP, all the rest is what RFC 8182
is supposed to do.

> (First: Maybe change "another large file download" into "another large
> snapshot download," because otherwise it kind of sounds like you're
> talking about the notification.)
> 
> The paragraph seems to imply that, if the adversary doesn't increment
> the serial along with RIPE, the RP will not download the file again.
> That the adversary needs to keep incrementing the serial to sustain
> the attack. Ok, makes sense.

Yes

> But it invites a deformation of the argument: If the adversary
> increments the serial *regardless* of RIPE, what's stopping the RP
> from downloading the snapshot again? Is there a requirement somewhere
> that states that the RP has to detect this type of RRDP session
> desynchronization? (Different serial, same snapshot.)
>
> (Yes, I'm aware rpki-client will discard the snapshot as soon as it
> notices the serial mismatch during transfer, but I'm talking about a
> generic RFC-compliant RP here. I know the "streaming RRDP file"
> feature is outside of the scope of your draft, but my point is that
> the paragraph doesn't really make sense in the context of the present
> RFC ecosystem as I understand it.)

I believe the adversial scenerio is executed most effectively by
carefully incrementing the serials in tandem with the victim, to make
the 'streaming XML decover RPs' also participate maximally.

> Alternate (slightly more generic) attack proposal:
> 
> Making sure the serial always matches the snapshot, point to a
> different available snapshot every time. The serial will always
> change, which means RPs will always have to download the snapshot,
> either because a new one is available (and there are no deltas), or
> because the lower serial will trigger an RRDP reset. You will not
> attack RIPE when they switch snapshots, you will guarantee RPs attack
> RIPE during every validation cycle.
> 
> Proposal:
> 
> > If the adversary keeps changing the notification's session metadata,
> > every next request to _https://badhost/notification.xml_ causes
> > another large snapshot download on the RIPE NCC servers, exacerbating
> > the issue. (For several popular RP implementations, this presently
> > requires that the malicious notification's session metadata always
> > matches the snapshot's session metadata.)

If the goal is to simplify, perhaps:

"""
An adversary which changes the RRDP session's metadata for every next
request to _https://badhost/notification.xml_ can cause yet another
large download on the victim's servers, exacerbating the issue.
"""

*********************************

Anyway, it seems your commentary focusses on the description of the
exploitability. I think you and I agree exploitation is possible, and
perhaps it is not so relevant what you and I exactly call the moving
parts in such scenarios.

So, shall I remove in section 2 starting at "Consider the following
example served" until the end of section 2?

I'd be happy to reduce Section 2 to a bare minimum and leave it as an
exercise for the reader how to exploit it if SOP is not in play. I don't
think it's all to useful to add text that we considered disallowing HTTP
query parameters and then decided it was fine afterall.

I think that in documents like these it is fine to focus on the desired
outcome solution, not on all the things that could've gone wrong without
the desired outcome solution in place. It'll make the document shorter,
(which I see as an advantage!)

Kind regards,

Job