Re: [sidr] Validation reconsidered draft status

[Carlos M. Martinez]

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


On 11/12/15 11:43 AM, Andy Newton wrote:
> 
>> On Nov 5, 2015, at 3:53 PM, Karen Seo  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
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
> 

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered draft status

[Stephen Kent]

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 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.

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 can continue discuss this 
constructively, and it is not certain a priori that it will be rejected?

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.



___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered draft status

[Stephen Kent]

Carlos,


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.

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.

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.

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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered draft status

[Karen Seo]

Hi, Andy,

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


On 11/12/15 9:43 AM, Andy Newton wrote:

On Nov 5, 2015, at 3:53 PM, Karen Seo  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.
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 should be smarter. Setting aside the 
hand-waving and lack of a concrete solution, these are not comparable proposals.
I defer to Steve on this,  I believe he intends to remove the 
remediation text.


Thank you,
Karen


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered draft status

[Tim Bruijnzeels]

> On 16 Nov 2015, at 19:16, Stephen Kent  wrote:
> 
> Andy,
>>> On Nov 5, 2015, at 3:53 PM, Karen Seo  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.
> 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.

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
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered draft status

[Andy Newton]

> On Nov 5, 2015, at 3:53 PM, Karen Seo  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
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered draft status

[Karen Seo]

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




On 11/5/15 8:59 PM, Carlos M. Martinez wrote:

Karen,

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

It is not the same topic.

-Carlos

On 11/6/15 5:53 AM, Karen Seo 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.

Respectfully,
Karen

On 11/3/15 4:21 AM, Christopher Morrow wrote:

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 (g...@apnic.net) 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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered draft status

[Sean Turner]

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

Title: Diff: text1.txt - text2.txt
 
 

 
 
 
 
 
 
 
   
   text1.txt   text2.txt  
  
 Validation of signed resource data using a target resourceValidation of signed resource data using a signing key that is
 certificate consists of verifying that the digital signature of thecertified in a resource certificate, coupled with a specific set of
 signed resource data is valid, using the public key of the targetnumber resources, consists of verifying that the digital signature of
 resource certificate, and also validating the resource certificate inthe signed resource data is valid, using the public key that is
 the context of the RPKI, using the path validation process.  Thiscertified by the resource certificate, and also validating the
 path validation process verifies, among other things, that aresource certificate in the context of the RPKI, using the path
  validation process.

  This path validation process verifies, among other things, that a
 prospective certification path (a sequence of n certificates)prospective certification path (a sequence of n certificates)
 satisfies the following conditions:satisfies the following conditions:
   
1.  for all 'x' in {1, ..., n-1}, the subject of certificate 'x'   1.  for all 'x' in {1, ..., n-1}, the subject of certificate 'x'
is the issuer of certificate ('x' + 1);   is the issuer of certificate ('x' + 1);
   
2.  certificate '1' is issued by a trust anchor;   2.  certificate '1' is issued by a trust anchor;
   
3.  certificate 'n' is the certificate to be validated; and   3.  certificate 'n' is the certificate to be validated; and
   
  
4.  for all 'x' in {1, ..., n}, certificate 'x' is valid.   4.  for all 'x' in {1, ..., n}, certificate 'x' is valid for the
 specific set of resources.
   
  
 Certificate validation entails verifying that all of the followingRPKI validation for a specific set of resources entails verifying
 conditions hold, in addition to the certification path validationthat all of the following conditions hold, in addition to the
 criteria specified in Section 6 of [RFC5280]:certification path validation criteria specified in Section 6 of
  [RFC5280]:
   
1.  The certificate can be verified using the issuer's public key   1.  The certificate can be verified using the issuer's public key
and the signature algorithm   and the signature algorithm
   
2.  The current time lies within the certificate's Validity From   2.  The current time lies within the certificate's Validity From
and To values.   and To values.
   
3.  The certificate contains all fields that MUST be present, as   3.  The certificate contains all fields that MUST be present, as
  
defined by this specification, and contains values for   specified by [RFC6487], and contains values for selected
selected fields that are defined as allowable values by this   fields that are defined as allowable values by this
specification.   specification.
   
  
4.  No field, or field value, that this specification defines as   4.  No field, or field value, that the [RFC6487] specification
MUST NOT be present is used in the certificate.   defines as MUST NOT be present is used in the certificate.
   
5.  The issuer has not revoked the certificate.  A revoked   5.  The issuer has not revoked the certificate.  A revoked
certificate is identified by the certificate's serial number   certificate is identified by the certificate's serial number
being listed on the issuer's current CRL, as identified by the   being listed on the issuer's current CRL, as identified by the
CRLDP of the certificate, the CRL is itself valid, and the   CRLDP of the certificate, the CRL is itself valid, and the
public key used to verify the signature on the CRL is the same   public key used to verify the signature on the CRL is the same
public key used to verify the certificate itself.   public key used to verify the certificate itself.
   
  
6.  The resource extension data is "encompassed" by the resource   6.  The resource extension data contained in this certificate
 

Re: [sidr] Validation reconsidered draft status

[Karen Seo]

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:

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 (g...@apnic.net) 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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered draft status

[Geoff Huston]

I disagree with the assertions Karen


> On 6 Nov 2015, at 7:53 AM, Karen Seo  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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered draft status

[Carlos M. Martinez]

Karen,

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

It is not the same topic.

-Carlos

On 11/6/15 5:53 AM, Karen Seo 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.
> 
> Respectfully,
> Karen
> 
> On 11/3/15 4:21 AM, Christopher Morrow wrote:
>> 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 (g...@apnic.net) 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
>>
>> ___
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
> 
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered draft status

[Karen Seo]

Geoff,

  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
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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered draft status

[Declan Ma]

> 在 2015年11月6日，13:16，Geoff Huston  写道：
> 
> I disagree with the assertions Karen
> 
> 
>> On 6 Nov 2015, at 7:53 AM, Karen Seo  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.
> 

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


> 
>> 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
> 
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered draft status

[Christopher Morrow]

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

On Tue, Nov 3, 2015 at 8:21 PM, Christopher Morrow
 wrote:
> 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 (g...@apnic.net) 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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] Validation reconsidered draft status

[Christopher Morrow]

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 (g...@apnic.net) 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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr