RIR TA's tree should've been considered invalid because of invalid signature identifier

[job]

Yesterday ARIN introduced incorrect algorithm identifier encodings in their RPKI data.

It appears that for some reason routinator's validation process did not catch this error and continued to produce VRPs based on cryptographically invalid data

A more detailed analysis of what transpired is available here http://sobornost.net/~job/arin-manifest-issue-2020.08.12.txt

ARIN confirmed the analysis was correct and is now working to restore CA services.

tested on routinator 0.7.1

[job]

A dump of the broken data is available here http://sobornost.net/~job/arin-broken-state-20200812.tar.gz

the RIR is expected to fix the issue in the next few hours

[partim]

I don’t agree with the conclusion that these manifests were cryptographically invalid and needed be rejected.

With regards to the parameters field of RSA 1.5 algorithm identifiers, RFC 4055, states:

    When any of these four object identifiers appears within an
   AlgorithmIdentifier, the parameters MUST be NULL.  Implementations
   MUST accept the parameters being absent as well as present.

This means that both versions are valid identifiers for RSA 1.5 signature with SHA256.

The question then is, are they the same algorithm identifier? Do they need to have the same DER encoding or is it enough that they identify the same algorithm with the same parameters?

I would argue that in this case the robustness principle applies and the second interpretation can be used since doing so doesn’t cause any harm. The certificate is has been correctly signed and all its metadata (which, in case of RPKI doesn’t carry any meaning anyway) is correct.

I understand that you want all RPKI validators to produce the exact same output all the time, but this incident proves that this is likely an unattainable goal if at the same time you aim for software diversity. There very likely are a large number of similar cases you will only ever uncover by someone accidentally triggering them. X.509 and CMS are complex beasts, even in their boiled down RPKI profile.

[jcurranz]

An interesting observation… it raises the question of validation for operation purposes (which very likely should apply the robustness principle) versus validation for purposes of assessing rigor of specification compliance (e.g. gcc’s -Wall switch equivalent) /John

…

On 13 Aug 2020, at 12:11 PM, Martin Hoffmann ***@***.***> wrote: I don’t agree with the conclusion that these manifests were cryptographically invalid and needed be rejected. With regards to the parameters field of RSA 1.5 algorithm identifiers, RFC 4055, states: When any of these four object identifiers appears within an AlgorithmIdentifier, the parameters MUST be NULL. Implementations MUST accept the parameters being absent as well as present. This means that both versions are valid identifiers for RSA 1.5 signature with SHA256. The question then is, are they the same algorithm identifier? Do they need to have the same DER encoding or is it enough that they identify the same algorithm with the same parameters? I would argue that in this case the robustness principle applies and the second interpretation can be used since doing so doesn’t cause any harm. The certificate is has been correctly signed and all its metadata (which, in case of RPKI doesn’t carry any meaning anyway) is correct. I understand that you want all RPKI validators to produce the exact same output all the time, but this incident proves that this is likely an unattainable goal if at the same time you aim for software diversity. There very likely are a large number of similar cases you will only ever uncover by someone accidentally triggering them. X.509 and CMS are complex beasts, even in their boiled down RPKI profile. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#365 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDV3MJ22RTVRYFA7HV2QXTSAQGEBANCNFSM4P6Q4NJQ>.

[job]

An interesting observation… it raises the question of validation for operation purposes (which very likely should apply the robustness principle)

That would be a somewhat perverted view on how to engineer robust networks :-)

An conceptual analogy may be that in BGP UPDATE messages which exhibit some encoding issue the receiver applies 'Treat-as-Withdraw` (previously the whole session would be torn down) instead of proceeding to interpret the NLRI information that supposedly could be decoded. A withdraw is considered the safer option.

versus validation for purposes of assessing rigor of specification compliance (e.g. gcc’s -Wall switch equivalent) /John

In this case compliance is not aspired merely for the fun of it.

The possibility for incremental deployment of RPKI on the global Internet is based on the premise that the validation system 'fails open', this means that the validators are the 'firewall' between the untrusted network channel input and the RTR clients that run on our EBGP edge routers.

I'd be very worried if there ever was the possibility of something being 'wrong in the RPKI' somehow triggering anything else than not-found validation state for EBGP routes. If anything is wrong with the RPKI data, it should not result in VRPs being emitted into the routing system.

I celebrate software diversity, some may know I tried hard to help produce more implementations exactly because I believe diversity is important. I opened this ticket because I wish that Routinator users too have access to a secure rigorous validation process suitable for production environments.

[partim]

Resolved via NLnetLabs/rpki-rs#130.