Subject: [sidr] Validation reconsidered draft status

From: Christopher Morrow <[email-masked]>
Date: Tue, 3 Nov 2015 20:21:20 +1100

During the meeting today (tues 11/3/2015) one of the authors of:
  draft-ietf-sidr-rpki-validation-reconsidered

noted that after the last set of updates and over the history of the
document (2+yrs) there's been no real support nor direction from the
working-group. Additionally, all co-authors noted that the lack of
support and direction meant that abandoning the draft seemed like the
best current direction.

The primary author: Geoff Huston ([email-masked]) is willing to toss
the XML over the fence to another author/editor if there is interest,
or to let the draft expire/die if no one is willing to take up the
pencil.

Over the next three weeks let's discuss the direction/end-goal and
determine if 'abandon' or 'new author' is the best course of action
here.

-chris
sidr-co-chair

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 5 Nov 2015 01:23:49 +1100

hurray! ambiguity in questions was raised by an interested party...

I'd rather do this Friday at the end of the meeting with a short
presentation/conversation.

-chris

---

From: Karen Seo <[email-masked]>
Date: Thu, 5 Nov 2015 15:53:55 -0500

Folks,

I think the authors have brought up some pertinent issues which have 
helped inspire other work which subsumes them.  So I thank them but 
agree that it seems appropriate to drop this draft since those issues 
are now being covered in other documents and those documents have 
additional detail.  Randy's I-D discusses INR transfers.  Steve's draft 
on adverse action provides a detailed analysis of the "operational 
fragility" of the RPKI in the face of attacks and errors.  So, if the 
adverse actions draft is adopted by the WG,  we (the WG) could use the 
requirements stemming from these two IDs as the basis for a solution(s) 
document.  Just personal preference, but I also find having one document 
per topic/issue (at least when they're as complex as is the case with 
the threat analysis) easier to follow and would also like to separate 
defining of issues and their requirements from describing the solution.

Respectfully,
Karen

On 11/3/15 4:21 AM, Christopher Morrow wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Sean Turner <[email-masked]>
Date: Fri, 6 Nov 2015 09:39:02 +0900

Here’s a file that shows the differences between the two procedures (I backed out the capitalization changes).  text1 is in 6487 (left) and text2 is in validation-reconsidered (right).

spt

> On Nov 04, 2015, at 23:23, Christopher Morrow <[email-masked]> wrote:
>

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 6 Nov 2015 10:59:35 +0900

Karen,

I disagree with your position. Our draft does not explore adverse
actions nor discuses transfers.

It is not the same topic.

-Carlos

---

From: Geoff Huston <[email-masked]>
Date: Fri, 6 Nov 2015 16:16:51 +1100

I disagree with the assertions Karen

> On 6 Nov 2015, at 7:53 AM, Karen Seo <[email-masked]> wrote:
> 
> Folks,
> 
> I think the authors have brought up some pertinent issues which have helped inspire other work which subsumes them.  So I thank them but agree that it seems appropriate to drop this draft since those issues are now being covered in other documents and those documents have additional detail.

this is the overall assertion that I disagree with.

>  Randy's I-D discusses INR transfers.

This is just one way to think about certificate-mediated transfer of resources between address registries. It does not necessarily address the brittleness of the overall RPKI when using the existing validation algorithm.

>  Steve's draft on adverse action provides a detailed analysis of the "operational fragility" of the RPKI in the face of attacks and errors.

As I said in the working group meeting, I oppose the adoption of this draft. It is by no means a complete list of “things that could go wrong” and as we continually find out in operations each and every day, what actually surprises us that goes wrong is stuff that we never expected to go wrong. This document pretends to be a comprehensive list of all things that could go wrong and such a pretension is at best a dangerously mistaken one. The suggested remediations rely on unspecified mechanisms that are at best using a liberal application of magic. It leads to a misapprehension that nothing else could ever go wrong, and therefore if we just concentrate on these things the result would be operationally perfect. I have yet to see such a theory of how to attain operational perfection withstand even one week in the field.

>  So, if the adverse actions draft is adopted by the WG,  we (the WG) could use the requirements stemming from these two IDs as the basis for a solution(s) document.

And that in a nutshell is exactly why I oppose the adoption of this document. It appears to me that this step assumes that the adverse actions has catalogued avery possible problem and now all we need to do now is to replace the magic placeholders with some action or other. I’m sorry but this premise is just not realistic and this approach in the draft is just not realistic for me.

>  Just personal preference, but I also find having one document per topic/issue (at least when they're as complex as is the case with the threat analysis) easier to follow and would also like to separate defining of issues and their requirements from describing the solution.

Just personal preference, but I would like the Working Group to address some basic design issues here that invoke brittleness in all kinds of known and unknown ways rather than play hunt the wumpus with some supposedly comprehensive list of everything that could ever possibly go wrong. ever.

regards,

  Geoff

---

From: Declan Ma <[email-masked]>
Date: Fri, 6 Nov 2015 15:07:01 +0800

> 在 2015年11月6日，13:16，Geoff Huston <[email-masked]> 写道：
> 

Geoff,

The way I think about “things that could go wrong” is different from you.

No one can enumerate all specific and concrete security problems as we are moving forwards with RPKI deployment and operations.

But reviewing RPKI operation security on the whole and establish a threat model is necessary as people did in other areas. One can easily find a bunch of RFCs that are intended to do so.

RFC 3833 Threat Analysis of the Domain Name System (DNS) 

RFC7132 Threat model for BGP Path Security 

RFC7375 Secure Telephone Identity Threat Model.

for instance.

And the adverse actions draft is intended to well shape the RPKI operation security problems by offering taxonomy that helps seek security mechanisms to safeguard RPKI operations.

Di

---

From: Karen Seo <[email-masked]>
Date: Fri, 6 Nov 2015 02:08:15 -0500

Geoff,
>> And that in a nutshell is exactly why I oppose the adoption of this document. It appears to me that this step assumes that the adverse actions has catalogued avery possible problem
Sorry for not being clear.  I did not mean to imply that this work is 
100% complete or to pre-empt the WG's right to modify the draft and 
decide when it is complete.  It could well be, as you suggest, that the 
adverse actions draft requires extension and modification. And that is 
the WG's prerogative.  However, I do believe this draft provides a good 
starting place for WG collaboration on the issue of what threats are 
faced by the RPKI and how they would impact it. And such an analysis 
(once vetted and approved by the WG)  would provide useful input towards 
picking which vulnerabilities most need addressing and how to address 
them, even if the analysis was not 100% comprehensive.
>> and now all we need to do now is to replace the magic placeholders with some action or other. I’m sorry but this premise is just not realistic and this approach in the draft is just not realistic for me.
I'm confused by this statement.  The threat analysis/attack model does 
not magically produce solutions.  What the draft does (IMHO) is to 
methodically go through possible attacks and describe the resulting 
impact if the attack is successful.  Whether or not the list of attacks 
is 100% complete, one can use the analysis to (a) prioritize the 
identified attacks/vulnerabilities as to impact (and therefore 
importance to mitigate) (b) generate the corresponding requirements for 
the solutions and (c) identify those attacks/vulnerabilities for which 
no reasonably feasible mitigation can be found, so that we know those 
dangers remain.   I agree that the more complete the analysis the better 
but I wouldn't throw out the approach.
> Just personal preference, but I would like the Working Group to 
> address some basic design issues here that invoke brittleness in all 
> kinds of known and unknown ways rather than play hunt the wumpus with 
> some supposedly comprehensive list of everything that could ever 
> possibly go wrong. ever. regards, Geoff 
Could the problem cases you mention in your draft be added to the 
adverse actions draft?   For example, there are categories for when the 
CA makes various kinds of errors.

Thank you,
Karen

---

From: Karen Seo <[email-masked]>
Date: Sat, 7 Nov 2015 00:31:05 -0500

Hi, Carlos,

Perhaps I've misunderstood your draft but to me it seems to claim that 
there are 2 areas that could cause problems.

 1. Page 4-5 discusses possible errors by CAs in issuing certificates
    that could cause subordinate certificates to fail validation. With
    regard to exploring adverse actions, what I meant is that your draft
    describes an adverse action (possibly several depending on how one
    interprets your text) that can be done by a CA by error (or
    maliciously or because of an attack).  And I believe the adverse
    action draft covers this or could be extended to cover it, if the WG
    feels the current text does not adequately describe this case (or
    cases).
 2. Page 5-7  talks about resource transfers as a source of concern. The
    way in which resource transfers can/will cause problems and the
    resulting impact will depend on how the WG decides to handle the
    transfers, the order of the actions, who does what, etc.   So while
    your draft does not define how transfers should be done, Randy's
    draft struck me as potentially addressing the issue or at the very
    least providing the necessary basis for evaluating its seriousness
    and what to do about it.

Karen

---

From: Andy Newton <[email-masked]>
Date: Thu, 12 Nov 2015 14:43:36 +0000

> On Nov 5, 2015, at 3:53 PM, Karen Seo <[email-masked]> wrote:
> 
> Folks,
> 
> I think the authors have brought up some pertinent issues which have helped inspire other work which subsumes them.  So I thank them but agree that it seems appropriate to drop this draft since those issues are now being covered in other documents and those documents have additional detail.  Randy's I-D discusses INR transfers.  Steve's draft on adverse action provides a detailed analysis of the "operational fragility" of the RPKI in the face of attacks and errors.  So, if the adverse actions draft is adopted by the WG,  we (the WG) could use the requirements stemming from these two IDs as the basis for a solution(s) document.  Just personal preference, but I also find having one document per topic/issue (at least when they're as complex as is the case with the threat analysis) easier to follow and would also like to separate defining of issues and their requirements from describing the solution.

If I’m reading your argument correctly, you’re saying that validation-reconsidered is not necessary because Kent’s adverse actions draft provides a solution.

Except that it doesn’t. Validation reconsidered stops the harm before it happens, where as the adverse actions draft says two things: 1) monitor and fix the harm after it has happened, and 2) RPs should be smarter. Setting aside the hand-waving and lack of a concrete solution, these are not comparable proposals.

-andy

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Nov 2015 12:16:23 -0500

Andy,
>> On Nov 5, 2015, at 3:53 PM, Karen Seo<[email-masked]>  wrote:
>>
>> Folks,
>>
I can't say what Karen may be thinking, but my argument is that 
validation-reconsidered
contains vague arguments about RPKI fragility and a technically 
ambiguous description
of a proposed change to 6487. What I believe is needed is a more 
rigorous description
of the problems being solved and a clear proposal of how to solve them. 
If the
co-authors who said they will assume responsibility for this doc make 
significant
revisions along these lines, then maybe the result will be worth pursuing.

> Except that it doesn’t. Validation reconsidered stops the harm before it happens, where as the adverse actions draft says two things: 1) monitor and fix the harm after it has happened, and 2) RPs should be smarter.
The harm described in validation-reconsidered is the generation and 
publication of certs that over-claim. The I-D does not stop that harm. 
It proposes to sweep it under the rug,
with a bandaid approach (that, as noted earlier) is technically 
ambiguous, as stated).

Adverse actions focuses mostly on defining the problem, in a more 
precise fashion.
It alludes to solution approaches that prevent the harm from having 
immediate,
adverse impact. The "RPs should be smarter" comment seems totally out of 
place.
> Setting aside the hand-waving and lack of a concrete solution, these are not comparable proposals.
Your are right that they are not comparable. One is very badly written, 
and could be
described as hand waving, and offers a "solution" that isn't well-defined.

The other is well written, defines problems in a rigorous fashion, and, 
after
making the changes suggested during the meeting, does not offer a 
remediation
proposal.

Steve

---

From: Karen Seo <[email-masked]>
Date: Mon, 16 Nov 2015 12:40:04 -0500

Hi, Andy,

Sorry to take so long to reply... I was out of the office for much of 
Thurs/Fri.  Responses in line below....

> If I’m reading your argument correctly, you’re saying that validation-reconsidered is not necessary because Kent’s adverse actions draft provides a solution.
Sorry, what I meant was that it would be a good idea for the WG to do a 
threat analysis which could then be used to prioritize issues and shape 
solutions but not contain solutions.  Do you agree with this premise?    
The adverse actions seems to me to be a good place to start.   If 
validation reconsidered identifies threats that aren't covered in the 
threat analysis, I think we should add them to the threat analysis.
> Except that it doesn’t. Validation reconsidered stops the harm before it happens, where as the adverse actions draft says two things: 1) monitor and fix the harm after it has happened, and 2) RPs s…
I defer to Steve on this,  I believe he intends to remove the 
remediation text.

Thank you,
Karen

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 17 Nov 2015 09:54:30 +0200

> On 16 Nov 2015, at 19:16, Stephen Kent <[email-masked]> wrote:
> 
> Andy,
> I can't say what Karen may be thinking, but my argument is that validation-reconsidered
> contains vague arguments about RPKI fragility and a technically ambiguous description
> of a proposed change to 6487. What I believe is needed is a more rigorous description
> of the problems being solved and a clear proposal of how to solve them. If the
> co-authors who said they will assume responsibility for this doc make significant

As I stated at the mic I am willing to work on making this document more clear (and shorter) *if* the working group agrees that we can work on this in a constructive manner. It is okay if we have different opinions if we can all respect them and discuss the content, staying away from hyperboles and personal remarks. Unfortunately this hasn't always been the case.

The second point I tried to make is that if it is already clear that consensus will never be reached on this, then spending more effort on it is a waste of everyone's time. I understand that there are no guarantees that consensus will be reached, but if there is a guarantee that consensus will *not* be reached, then the exercise is pointless.

So far this discussion actually looks promising and more constructive than it has been. Can I interpret your statement about 'maybe the result will be worth pursuing' to mean that you agree that we can continue discuss this constructively, and it is not certain a priori that it will be rejected?

Thanks,

Tim

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 17 Nov 2015 12:32:31 -0300

Karen/Steve,

Sorry for getting back to this late.

Andy is right on the money: the text validation-reconsidered has
possible 'things that can go wrong' could be removed but the main idea,
as Andy says, is to engineer robustness into the system in a way that
the system will be more resilient in the face of unexpected events that
we might have or have not thought about.

Now, if you are proposing that we could have a single document
enumerating threats and 'other things that could go wrong', I thing I
could agree with that on the understanding that we agree to clearly
separate threats from remediation proposals. This means probably
removing some text from Steve's draft as well.

regards,

-Carlos

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Nov 2015 15:13:21 -0500

Tim,

> The second point I tried to make is that if it is already clear that consensus will never be reached on this, then spending more effort on it is a waste of everyone's time. I understand that there…
I understand your reluctance to invest time into a document that may or may
not become an RFC. But, that is what all of us do when we write drafts. 
There
are no guarantees; many I-Ds become RFCs, but not all.

I cannot guarantee that the WG will reach consensus on this draft. 
First, the consensus
call if made by the WG chairs, not by me. Second, I assume you and your 
colleagues
plan to re-write the document, and so it's premature to comment on the 
likely
success of a revised document.
> So far this discussion actually looks promising and more constructive than it has been. Can I interpret your statement about 'maybe the result will be worth pursuing' to mean that you agree that we…
I am willing to discuss this constructively.  I provided extensive comments,
including numerous edits to try to improve the text several months ago. If
you and Carlos and Andy are serious about going forward, I suggest two 
actions:
      1. review the edits I suggested month ago and either adopt them
        or explain why they are rejected

     2. reword the proposed solution so that it is technically 
unambiguous and
     aligned with RFC 6487. In rewording the solution description, 
please address
     the issues I noted, reproduced below.

    The text in step 6 seems a bit vague. It refers to a “resource set”
    but that phrase is not defined in this document. Looking at 6487,
    the phrase appears twice, in Sections 4.8.10 and 4.8.11. In those
    sections it is referring to the set of resources acquired from a
    parent when the inherit bit is set. If the intent is to use this
    phrase to refer to the set of resources extracted from an RPKI
    certificate, irrespective of whether the inherit bit is set, this
    text should say so.

    The security considerations section says “… the validation path
    encompass the resources that are included in the validation query.”
    One might read this and infer that a set of INRs is an input to the
    validation algorithm. But 6487 does not say INRs are a separate
    input to validation. A certificate to be validated is an input to
    this algorithm, and I assume that was what is implied in step 6 and
    in the text quoted above. If my assumption is correct, this should
    be stated clearly in both places.

    Thinking about this in more detail, I fear that the results from the
    modified algorithm will not yield what you seem to want, at least
    not in all cases. If one validates only router certificates and EE
    certificates for (non-PKI) signed objects, e.g., for ROAs or
    Manifests, then the outcome will yield what I think you want.
    However, when validating a CA certificate that “over claims” the
    certificate will be considered invalid by the revised step 6, just
    as with the current validation algorithm. (The over claiming could
    result from some types of CA errors or attacks, or during an “free
    style” resource transfer.)

    RP software may validate each CA certificate that it initially
    acquires, before fetching subordinate signed products. This is a
    reasonable strategy to avoid DoS attacks based on returning bogus
    certificates to an RP. Also, when a cached CA certificate is
    discovered to have changed, an RP probably will validate it before
    adding the certificate to the cache. In these cases, the revised
    step 6 will treat this certificate as invalid, because it contains
    resources not present in all parent certificates. Thus all
    certificates and signed products below it will become invalid. So, I
    don’t believe the change to step 6, as described in your I-D, and as
    interpreted above, will accommodate the motivations described in the
    I-D that you plan to replace with this one.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Nov 2015 15:19:16 -0500

Carlos,

> we might have or have not thought about.
I agree that improving system robustness is a generally good idea.
However, if one argues for a major change to the existing system,
the justification needs to be precise, and compelling, and well
defined.

Addressing unanticipated events is a good idea too, but addressing
anticipated, clearly identified events seems even more important.
That's why I believe we ought to take into account the events described
in adverse actions when we consider making any significant change to
the cert path validation algorithm.
> removing some text from Steve's draft as well.
I stated that I would remove the sections on detection and remediation
during the meeting. By the end of this week I hope to have a new version
posted which does that, and which adds a generic, additional concern that
addresses the issue Sriram raised. The revised adverse actions document
should meet the criteria you state above.

Steve