Ideas on database information and key trust

[mxsasha]

In the current design, each NRTMv4 endpoint can be authenticated using a public Ed25519 key. This is a great improvement over the complete lack of authentication in NRTMv3+FTP. But, it creates the problem of key distribution: how will users know what key to trust? How are users made aware that the key has been rotated? How do they distinguish an attempted hijack from a legit key rotation?

We previously floated asking for an IANA registry of IRRs including keys. This could be nice, it could also include the NRTMv4 endpoint, information which is currently a bit scattered. To some degree, this moves the problem to IANA: when I mail and say "hey I'm RIPE and here's our new key and URL", how do they know I'm allowed to do that?

One answer to that is: "IANA should verify against publicly known sources like ripe.net". For most if not all IRRs, we would all instantly agree on which website is authoritative. So my new idea is: let's skip over that IANA registry step, and publish IRR information in a structured format on a well known URL on the authoritative domain of the organisation that runs the IRR.

https://ripe.net/.well-known/nrtm.json could contain:

[
    {
        'database': 'RIPE',
        'update_notification': 'https://ripe.net/db/nrtmv4/ripe/notification.xml',
        'key': '<base64 of key>'
    },
    {
        'database': 'RIPE-NONAUTH',
        'update_notification': 'https://ripe.net/db/nrtmv4/ripe-nonauth/notification.xml',
        'key': '<base64 of key>'
    }
]

Because it's structured, a user would only need to configure:

sources:
    RIPE:
        nrtm_trusted_domain: ripe.net
    RIPE-NONAUTH:
        nrtm_trusted_domain: ripe.net
    RADB:
        nrtm_trusted_domain: radb.net

With this, IRRD can pull the file, find the update notification file, verify it, and do NRTMv4 as normal. This file is small and rarely updated - the actual NRTMv4 endpoint, which is much larger and updates frequently, does not need to be on the same host, it is trusted from the signature. IRRD should periodically poll the well known file, at a low rate, to find key rollovers.

By specifying the source explicitly in the client configuration, we avoid ripe.net suddenly distributing keys for RADB. IRRD should only allow HTTPS to retrieve the well known file.

Upsides:

• Configuration for mirror clients only needs to have the name of a source and a trusted domain.
• Mirror clients automatically roll over keys without operator intervention.

Downsides:

• We place all trust on the well known URL on the trusted domain. But it kind of comes down to that already. Human intervention can help, I think people will ask questions if ripe.net suddenly says to mirror from ripe-nrtm.biz, but more subtle attacks might still slip through if the trusted domain is compromised.

Adjacent to this: the signature file should allow more than one signature, for signing with multiple keys. Regardless of method, not all clients will update to a new key at the same time.

[job]

We can mention in the draft "REMOVE BEFORE PUBLICATION: this section is wide open to suggestions / ideas" and punt this discussion until after draft submission.

[stkonst]

Hmmm... It's not a bad idea and I do appreciate the simplicity in the mirror client config. Upsides are strong, especially the automatic key rollover task.

I do recognize though the extended trust on the well-known URL, but I believe nowadays is less of an issue.

My preference is to adopt Sasha's idea and propose it in the draft for completeness of the procedure but we shall prepare ourselves for extended Q&A on this subject during open discussion (and be open to alter this subject with an alternative idea).

[mxsasha]

I agree, will make a PR.