Subject: [Sidrops] RFC 8360 / 6487 (Was: RPKI Outage Post-Mortem)

From: Job Snijders <[email-masked]>
Date: Tue, 12 Jan 2021 19:27:27 +0000

Dear group (specifically George, Geoff, Tim, Carlos, Andrew & Daniel),

I'd like to ask SIDROPS to read this message
https://www.ripe.net/ripe/mail/archives/routing-wg/2021-January/004220.html
(please ignore point 1 & 2 as those are now resolved) 

What is the current plan to get RFC 8360 deployed at scale? Is this on
anyone's radar?

The spec has in the making for ~ 8 years and seems to contain a lot of
valuable insight. To me RFC 8360 seems to be to RPKI what RFC 7606 is to
BGP. A revision to increase operational robustness, except... 7606
actually got deployed :-)

Which of the Trust Anchor will be first to flip the switch?

Or... do CA implementers & operators consider jumping to the new RFC
8360 codepoint too risky of a move... and should an alternative strategy
be devised?

Was it (in hindsight) a mistake to not deprecate RFC 6487, but instead
specify a new optional alternative policy?

Kind regards,

Job

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 15 Jan 2021 12:21:50 +0100

Hi Job, all,

This might be of renewed interest:
https://tools.ietf.org/html/draft-va-sidrops-deploy-reconsidered-01

Presented at IETF104:
https://www.ietf.org/proceedings/104/slides/slides-104-sidrops-deployment-of-validation-reconsidered-00

The 8360 approach had some controversy in the past. But I would be happy to see a constructive discussion on its deployability. The document above is an attempt at starting that dialogue.

Tim

> On 12 Jan 2021, at 20:27, Job Snijders <[email-masked]> wrote:
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Job Snijders <[email-masked]>
Date: Fri, 15 Jan 2021 14:30:15 +0100

Dear Tim,

> https://www.ietf.org/proceedings/104/slides/slides-104-sidrops-deployment-of-validation-reconsidered-00

Thank you for these pointers, very informative.

It is now clear to me rpki-client has some work to do in order to
participate in progressing the deployment of the reconsidered validation
strategy in some form. It all starts with implementing support for RFC 8360 :-)

> The 8360 approach had some controversy in the past. But I would be
> happy to see a constructive discussion on its deployability. The
> document above is an attempt at starting that dialogue.

There being an OID (and thus a role for CAs to play in deploying 8360)
is a double-edged sword: one the one hand a large enough CA could
attempt to force the market to adopt the reconsidered validation
strategy by setting the new OID, on the other hand the CA might not be
large enough to pull that off.

It seems in the best interest of Relying Parties to not reject
overclaiming CAs, and in the best interest of CAs for their constituent
Relying Parties to use the revised strategy. I think George aptly
characterizes this as a 'community-wide risk'.

To me it seems the way the incentives are stacked, deploying a revised
strategy /should/ exclusively be a 'validator problem', rather than
something where CAs need to take action. However, a new OID having been
defined makes deployment a challenge which cannot exclusively be
resolved by just upgrading the validators, now it potentially involves
tens of thousands of Certificate Authorities. I can imagine how some
controversy came to be.

Looking at my publication point's log files it appears 95% of relying
parties upgrade *at least* once every 15 months. Any deployment plan
with *more* dependencies than 'just RPs upgrading their validators',
will have to take such numbers into consideration, and unfortunately
there is the risk of new (not revised) validators joining the ecosystem
in the next 15 months.

I have some todo items on this topic, I'll report back later. Thanks
again for your information and pointer to deploy-reconsidered draft!

Kind regards,

Job