Subject: Re: [Sidrops] request for call for Working Group adoption draft-spaghetti-sidrops-rpki-validation-update

From: Christopher Morrow <[email-masked]>
Date: Thu, 22 Apr 2021 13:46:17 -0400

Not a lot of follow on this... (well, public follow up)

So, I propose this course of action:
  1) this document serves as a 'requirement (and possible solution)' that
sidrops used to identify a problem
  2) send this along as a query/question to the protocol group (IDR) with a
request to:
     a) say: "go forth, this change seems ok, it's small and such"
     b) say: "Good googley-moogley! what are you crazypants people on
about?? of COURSE this needs to be reviewed... please have AD-foobar spin
up SIDR to properly handle this!! TUT-TUT! How cloud you conceive of a
world other than this!!"

      and answer back in 2wks time, one fort-night! and two farthings! (or
something, farthings are metric)

provided no one screams at me about this WHILE I WRITE THE NEXT EMAIL.. we
can send an adoption call/etc in 2wks time OR jump back into our SIDR
pantsuit and get to the business of business.

-chris

On Thu, Mar 25, 2021 at 6:45 PM Christopher Morrow <
[email-masked]> wrote:

> it seems to me this could be framed as:
>   "Hey, this problem with the protocol is a problem, it's raising problems
> for operations
>     of the systems involved. Let's get the size/shape of the problem
> figured out and get
>     some requirements for a change together to have the SIDR WG fix this
> protocol problem"
>
> that might be hard with SIDR gone, but there are a bunch of ex-SIDR now
> SIDROPS folks in
> SIDROPS who can say:
>   "ok, this seems insane, run fast in the opposite direction!!"
> or:
>   "Err, this isn't horrible, maybe this is easy to just fix in a proposal
> here?"
>
> -chris
>
>
> On Wed, Mar 10, 2021 at 1:12 PM Randy Bush <[email-masked]> wrote:
>
>> >>> I'd like to request the chairs to consider initiating a call for
>> >>> working group adoption of
>> draft-spaghetti-sidrops-rpki-validation-update
>> >>
>> >> this is a protocol change and a serious one, and hence does not belong
>> >> in an ops group
>> >
>> > There is ongoing operational problem
>>
>> most protocol problems cause operational problems.  it is a measure of
>> their severity.
>>
>> randy
>>
>> _______________________________________________
>> Sidrops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sidrops
>>
>

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 22 Apr 2021 18:54:35 +0100

Christopher Morrow wrote on 22/04/2021 18:46:
>    1) this document serves as a 'requirement (and possible solution)' 
> that sidrops used to identify a problem
>    2) send this along as a query/question to the protocol group (IDR) 
> with a request to:
> about?? of COURSE this needs to be reviewed... please have AD-foobar 
> spin up SIDR to properly handle this!! TUT-TUT! How cloud you conceive 
> of a world other than this!!"
>        and answer back in 2wks time, one fort-night! and two farthings! 
> (or something, farthings are metric)

do we need to involve IDR?  Hard to tell really. Will they get upset if 
they aren't consulted?  (+ will they get ideas if they are?)

> provided no one screams at me about this WHILE I WRITE THE NEXT EMAIL.. 
> we can send an adoption call/etc in 2wks time OR jump back into our SIDR 

sounds good.  The proposal doesn't seem to be horrible, several software 
stacks have implemented it _and_ the rpki hasn't fallen over yet, so it 
seems like so far, it's not a regression and it seems to fix something, 
so ... yay?

Nick

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 22 Apr 2021 13:59:53 -0400

nick got me before done...

> they aren't consulted?  (+ will they get ideas if they are?)
I believe the process we were pitched when SIDR was --'d from existence was:
  "If you (sidrops) see a problem, you should write a document that serves
    as the problem description and requirement for fix-action. Take the
document
    to IDR, who'll promptly do the 3-stooges: "not it" maneuver and hand us
off to
    the AD who will SIDR++ and then we can chat about the problem in the
SIDR
    venue, with possible protocol changes documented/implemented there."

I was proposing that the current document under discussion seems like the:
  "there is a  problem, we have a requirement to fix it, kthxbi!"

> seems like so far, it's not a regression and it seems to fix something,

ok!

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 22 Apr 2021 19:04:00 +0100

Christopher Morrow wrote on 22/04/2021 18:59:
> I believe the process we were pitched when SIDR was --'d from
> existence was: "If you (sidrops) see a problem, you should write a
> document that serves as the problem description and requirement for
> fix-action. Take the document to IDR, who'll promptly do the
> 3-stooges: "not it" maneuver and hand us off to the AD who will
> SIDR++ and then we can chat about the problem in the SIDR venue, with
> possible protocol changes documented/implemented there."

Right, so bureaucratic mumble in order to make sure that the tickboxes 
which required the tickboxes to be ticked, are ticked.  Great, wfm.

Nick

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Apr 2021 11:14:04 -0700

while i suspect that idr will not be overly excited, i am fairly sure
the security community, especially the pki folk, will be *very*
interested

randy

---
[email-masked]
`gpg --locate-external-keys --auto-key-locate wkd [email-masked]`
signatures are back, thanks to dmarc header butchery

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Apr 2021 11:15:25 -0700

ans, imino, it would be nice if, before the document went into "change
this change that" it went a bit more deeply into what problem is being
solved and a higher level view of how it is being solved.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 22 Apr 2021 19:19:01 +0100

> solved and a higher level view of how it is being solved.

yes, please.  The detail is in there, but you really have to sit down 
and think hard about what it's doing before it makes any sense, and even 
then you're left wondering if you really understand what's going on at all.

Nick

---

From: Job Snijders <[email-masked]>
Date: Tue, 27 Apr 2021 13:14:33 +0200

> the security community, especially the pki folk, will be *very*

The 'security community' is most welcome to provide review! Please
invite them. They should be interested! I look forward to read actual
arguments for- or against- the proposal (which is to apply the RFC 8360
validation algorithm to today's most popular policy OID). The SIDROPS
working group definitely would benefit from more scrutiny. :-)

The purpose of the internet-draft is to have a actual proposal in hand
for discussion. The draft in its current form should be suitable for
this purpose, it points at a problem, and it describes a solution.

I am not exactly thrilled to go pound sand via a decades long
'requirements' -> 'evaluation' -> 'solutions' dance, especially since
this exact discussion already is 10+ years old. From what I understand,
no IETF tool was left unused to prevent this validation algorithm from
actually being deployed.

A call for working group adoption will make it clear whether the working
group is interested to continue discussion of the problem at hand and
the potential solution. If the working group does not wish to adopt this
document, so be it.

Even if the working group does adopt the internet-draft, I am not
certain it'll make it to the RFC publication queue. Some study and
testing is warranted. WG adoption does not equate RFC publication.

The proposal *is* complicated (just like the current algorithm actually
is quite complicated), and there are additional complications related to
whether technical debt exists (or not exists) in 'libcrypto'. At the
same time all validators already have a bunch of workarounds for
rfc3779 'libcrypto' quirks, and the APIs are diverging as years go by.

It would be my preference to focus discussion on the technical merits of
RFC 8360-algorithm and any potential positive or negative implications,
rather than focus on bureaucratic process.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Tue, 27 Apr 2021 13:24:12 +0200

On Thu, Apr 22, 2021 at 06:54:35PM +0100, Nick Hilliard wrote:
> The proposal doesn't seem to be horrible, several software stacks have
> implemented it _and_ the rpki hasn't fallen over yet, so it seems like
> so far, it's not a regression and it seems to fix something, so ...
> yay?

Small point of correction, as far as I know none of the validators is
applying the 'new' algorithm to 'old' codepoints. None of the validators
merged code to do so into their main branch.

We provided these 3 code changesets for illustration purposes, to make
it clear that the 9 pages of hard-to-read document update shuffle work,
the ask to validator implementers actually is quite straight-forward and
easy to implement (if the community chooses to do so).

https://github.com/job/FORT-validator/commit/ff5f4b9313d5c553fa13bae427acb69665977727
https://github.com/job/rpki-rs/commit/d9fa8c72cf83ed6f25e4420eaaa9054078f15bc3
https://marc.info/?l=openbsd-tech&m=161011710120123&w=2

I fully expect each validator implemeter to want to do additional
refactoring/cleanup rather than verbatim copy+paste the above 3
changesets.

There is no deployed code, but the 3 links make it clear it is trivial
to get to a state of deployed code.

In order for validation implementers to adopt something similar to the
above changesets, some in the community requested an internet-draft
exists to reference. Making changes of this nature without an at least
an internet-draft existing would be detrimental to the cohesion of the
ecosystem.

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Tue, 27 Apr 2021 09:40:15 -0700

> invite them. They should be interested!

traditionally, it is the author(s) and the wg chairs who initiate this.
i suggest saag for starters; but ykmv

randy

---

From: Job Snijders <[email-masked]>
Date: Thu, 29 Apr 2021 20:38:20 +0200

> i suggest saag for starters; but ykmv

thank you for this pointer. I'm willing to work to present a case to the
SAAG experts and invest time to bring non-sidrops experts up to speed on
what the problem and context is, and then study the implications of the
proposed solution.

Of course, contigent on this working group being willing to adopt the
internet-draft. :-)

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 Apr 2021 12:24:57 -0700

> what the problem and context is, and then study the implications of the

who knows?  maybe they might even have something to teach us.

randy