Re: [Sidrops] weak validation is unfit for production (Was: Reason for Outage report)

[Tim Bruijnzeels <[e-mail]>]

Hi,

> On 29 Aug 2020, at 20:48, Job Snijders <[e-mail]> wrote:
> 
>> This is why I believe Tim’s suggestion for a flag day sounds
>> reasonable to me. We have to inform CAs about the impact changing the
>> behaviour of RPs has on them. 
> 
> A flag day to release a security update? Flag day's generally are used
> for other types of events.

To be clear: I suggested a flag day for encoding issues which are not *critical*. No CA is big enough to fail if there is a critical issue.

Fact is that if you take the position that any object which is not 100% specification compliant MUST be considered invalid, then NONE of the current validators are secure.

The ARIN issue was related to wrong encoding. The relevant RFC is pretty easy to misinterpret. But while there is a mandated encoding here, the error did not change the semantics. Furthermore the signature algorithm is defined by the RPKI RFCs - and the object has a whole could be validated. There never was a chance of different interpretations. There never was a chance of the signature being valid over modified content. So, wrong as this may have been, qualifying this as a critical issue is somewhat questionable. And given that the RFC was not very clear, it was right that RP implementers questioned the issue raised before implementing.

I could make equally bold statements on how routinator with the --strict option is in fact the only secure validator, because all others accept BER (not DER) encoded MFT and ROA objects. BER encoding is more complicated to decode - one issue in particular is that you do not necessarily know the size of compound values up front, and this has led to security issues in other applications. Surely, this is at least as bad, quite possibly worse. In practice, of course, we downloaded the objects and we can check their size before ending up here. So, while it is wrong, I would actually claim that this is not *critical*.

This should not stop us from improving. On the contrary. We can all learn from each other here. It is a very good goal to aim for 100% compliance, but it's going to require work from everyone to get there. This is why I suggested a flag day. Let's just focus our energy on working with each other, shall we?


- RP compliance checking

It is not easy to get to 100% checking in RPs. You can only test for things that you can think of - or things your library developers (openssl, bouncy castle etc) have thought of..

In days long past Rob Austein and Andrew Chi (then BBN) and I (then RIPE NCC) met to discuss validation corner cases. Andrew was able to generate all kinds of broken objects that our library simply could not generate (we could generate objects that we believe to be valid only). So, I was very grateful that he could do this and we could test our validation software. These objects are still used for regression testing in the RIPE NCC validator today. You can find them (100s of corner cases) here:
https://github.com/RIPE-NCC/rpki-commons/tree/master/src/test/resources/conformance

The ARIN encoding issue is not in there. Still, maybe this kind of set up can be useful for RP implementors again. It could be revived, extended, and hopefully be of use for all.


- CA compliance

Most implementations have code bases going back to 2011 or earlier. Most have automated tests in place using rcynic and/or the ripe ncc validator. Nowadays there are many more options available. My advice would be that all CA developers start testing with all RP implementations they can get their hands on, and use 'strict mode' where available.


As for processes.. if we can get RP and CA developers to agree, I think we can move forward on this without the need for an RFC even. It's a matter of organising things for sure. But I believe that other flag days (e.g. DNS) were just co-ordinated between all parties involved.


Kind regards,
Tim