Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-07.txt

[Ties de Kock <[e-mail]>]

Hi Job,

I don't expect changes to the draft this late in the process, but I think
it would be good to share these concerns.


> On 14 Oct 2021, at 18:22, Job Snijders <job=[e-mail]> wrote:
> 
> On Thu, Oct 14, 2021 at 05:07:33PM +0200, Ties de Kock wrote:
>>> 4.2.1:
>>> 
>>>      This field is an integer that is incremented (by 1) each time a
>>>      new manifest is issued for a given publication point.  This field
>>>      allows an RP to detect gaps in a sequence of published manifests.
>> 
>> I would really like it if we could leave this open and allow arbitrary
>> increments. It's what is out there in the wild, and RPs can not check anything
>> against manifestnumber either: Not all of them are guaranteed to be visible. 
> 
> But isn't that kind of the point though? To be able to detect whether an
> RP saw all of them, because it is not guaranteed an RP will have
> visibility into all of them?

What would an RP learn from this? Are there any attacks that this visibility
can prevent?

Keep in mind that a malicious CA can sign whatever it wants. And that an on-path
attacker or malicious repository can make objects valid/invalid by presenting
different sets of objects (so there is no need to sign objects if you want to
remove objects from validation).

At the same time, there are many legitimate scenarios in which an update is
never externally observable. So RPs can not 'learn' anything from it - it will
happen many times a day. I will describe a straightforward one below:

We consider a CA that processed ~2K updates an hour in a repository. Two objects
on the same manifest are updated in short succession. After each update, a new 
manifest is issued. The CA supports RRDP and rsync.

The updates are sent to a RRDP publication server synchronously (unlikely for
real implementations). The RRDP publication server processes the two publish
(w/ hash, so replace) operations before issuing the next delta. The update is
never visible in RRDP.

The rsync repository is written to disk batch-wise and revisions are kept around
for two hours. The CA does not have the performance (e.g. disk space, IOPS,
iO bandwidth) to write all 2000 revisions an hour to disk. The rsync repository
is written after both updates are processed. The update is never visible in
rsync.

In some scenarios (a lot of updates, or during a key-roll) you can even have
_many_ manifests that are not visible this way.

TLDR: I argue that in the real world, (potentially many) manifest updates will
never be externally observable and that a malicious repository can often cause
the same result for RPs, without signed objects.

At the same time RPKI has a beautiful property compared to the web PKI: an object
needs to be widely visible (and thus easy to detect!) to affect the default free
zone.

If you have an attack scenario where you can detect the behaviour of a malicious
CA this way, while that attack can not be performed by an on-path attacker,
please elaborate.

>> Strict incrementing counters are also a point of contention in implementations
>> due to database locking on the parent CA.
> 
> Can you elaborate on this aspect?

It is an implementation detail about parallelism and fine-grained locking (on DB
level) that does not lend itself well to description on a list. For manifests it
likely is no real concern. For serial numbers our implementation needs arbitary
increments due to this concern.

>> Existence/absense of manifests of a compliant CA is visible through the CRL. And
>> it does not make behaviour of a sloppy CA invisible.
>> 
>> I would also like to revisit 4.2.2.
>> 
>>>  letter extension.  The extension MUST be one of those enumerated in
>>>  the "RPKI Repository Naming Scheme" registry maintained by IANA
>>>  [IANA-NAMING].
>> 
>> Since the content of the registry is dynamic, I think it would be good to
>> clarify that encountering an unknown extension must not result in a failed fetch.
>> If RPs become intolerant to new filenames using an extension not in the
>> registry (for example .asa) would require a flag day. 
>> 
>> While reducing ambiguity in the results that RPs have when processing manifests
>> is good I don't think rejecting unknown types is worth the downside.
> 
> A flag day can be avoided by putting the .asa object in its own
> Publication Point: then the PP fails on older RPs (which is not a
> problem), and works as expected on newer RPs.

This is a lot of implementation work if there is no attack that it prevents.
It also forces a CA to triple (the CA needs to maintain the PP incoming from
parent plus two children) the number of manifests it needs to keep up to date
per CA, or update less often and open a longer window for replay attacks.

What do you think of his strategy:
  * RPs that do not download unknown extensions do not consider those when
	validating a manifest. Unknown files can not result in a failed fetch.
  * If a new object is "safe" (it does not change the meaning of other objects
	such as GBR) we can add the object with the same manifest version.
  * A new object profile that changes, to whatever degree, the effect of objects
	on the current manifest, requires a new (minimal) version of the manifest.

> 
> Since for (for example) the .asa object type the early allocation
> process is used, I think there is sufficient time between
> 'new idea' -> IANA registry update -> 'deployment in the wild'.
> 
> RP implementers need to stay up-to-date on what RPKI object types
> currently exist, which seems reasonable. I think there is value in clear
> guidance on what RPs should expect and not expect.

While I think people should update quickly, given the update rate I see in data
I think this is a tricky route to go. Updates are slow. For example: despite a
lot of effort there are still ~240 active RPKI Validator 3 instances out there
and about half of those appear to be builds from more than a year old [0].

> For example, rpki-client only attempts to sync currently known
> filetypes, this hopefully limits the (potential) garbage RPs pull in:
> https://github.com/openbsd/src/commit/22ca817fdd32d4cc08710821dad014cf18d1cd85

That is a nice local improvement in security! 

Kind regards,
Ties

[0]: Current numbers will differ - I read this from a chart with data up to the
first of september.

> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops