Re: [Sidrops] 6486bis: referenced object validation

[Job Snijders <[e-mail]>]

On Fri, Dec 04, 2020 at 11:44:17AM +0100, Tim Bruijnzeels wrote:
> > On 4 Dec 2020, at 11:40, Job Snijders <[e-mail]> wrote:
> > On Fri, Dec 04, 2020 at 11:16:51AM +0100, Martin Hoffmann wrote:
> >> Under this approach, the manifest expresses which objects the CA
> >> intended to publish. If all the objects listed on the manifest are
> >> present with a matching hash, the publication point reflects the
> >> intent of the CA and can be processed. If it contains invalid objects,
> >> these can be discarded individually.
> > 
> > Indeed, I believe you've now captured the essence of why manifests
> > exists at all. This is what rpki-client & FORT seem to have implemented.
> 
> I suggested this in August:
> https://mailarchive.ietf.org/arch/msg/sidrops/Mldz5a43kPPotslF9bpNz10rysk/
> 
> I think a lot of this could have been avoided if we had this
> discussion then, but I welcome this now..

Looking back I'm at a loss how "a lot of this" really could've been
avoided. What additional steps or process should I have followed for
NLNetLabs/RIPE/Cloudflare to sooner understand the problem with their
implementation choices and encourage those organisations to provide a
solution to their users?

As you know, I reported 'this' as a problem in February 2020 to sidrops@

OpenBSD rpki-client implemented the 'this' solution already in March
2020 https://github.com/openbsd/src/commit/8e07ef58f8a3812e87e1b5cf4d956ba264438cd5

FORT implemented also implemented the 'this' solution already back in
March 2020 https://github.com/NICMx/FORT-validator/commit/0ad2c3da34827b68c4f524c0c50f223746af91a5

To protect its business, NTT deployed 'this' in their transit-free
network in April 2020, further proving the viability of the approach on
global scale.

I reported 'this' again as a problem & mentioned the solution in April
2020: https://github.com/NLnetLabs/routinator/issues/319

We had *multiple* virtual SIDROPS meetings where I and others kept
repeating the issue and the solution, in simple english: ignore the
manifest when files are missing or corrupted. Additionally, ignore
objects that are expired or otherwise invalid.

Two RP implementers told me they *first* wanted to see a nearly finished
or even published RFC, before making any changes to their code. I think
RFC-first-code-later is an entirely unworkable model for cryptographic
software actively used in the field. It seems weird to me to set the bar
so high before addressing simple software defects. Conversely, IDR
requires 2 implementations *before* RFC publication (which helps avoid
lots of problems in RFC texts^W^W^W^W^W^W^Wimprove quality of RFCs), a
ritual which I think should be followed by SIDROPS as well.

RFC compliance (or a perception thereof) is very important for
system interopability, but not the end goal in and of itself.

The real goal is to keep the network running, where in this context our
role is to create software for network operators for them to securely
validate the wishes of the Internet number resource holders.

We have to keep the Internet running *while* we discuss things in IETF.
Drafts/RFCs are the byproduct, they come after the coding effort and
deploying the code.

Kind regards,

Job