Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-00.txt

From: John Curran <[email-masked]>
Date: Tue, 28 Oct 2014 20:17:31 -0300

On Aug 11, 2014, at 11:58 AM, Tim Bruijnzeels <[email-masked]> wrote:
> ...
> The *one* thing I (and I believe we..) challenge is whether the an overclaimed resource should invalidate a complete certificate, instead of invalidating just the resources at hand, but allowing the remainder.
> ...
> The following two we may be able to mitigate technically, because we are dealing with co-operating parties:
>  @1 There is a mis-timing in certificate shrinking in a transfer between co-operating parties.
>  @2 There is a mis-timing in the parent publishing a cert with extended resource, and issuing it to the child, and the child using those resources in turn.
> 
> But this is the one that has me scared. It is not the issuing CA being sloppy, it’s a problem between them and *their* parent:
> @1 The *grand*-parent shrinks the *parent* certificate without the parent knowing about this, and some of these resources appear on the, now overclaiming, child certificate. The grand-parent and parent are not involved in an active transfer process. They may not agree that the resource in question should be removed, or the grand-parent may have shrunk these resources in error.
> 
> By rejecting the overclaiming child certificate completely I think we are being too harsh, or pedantic even. We know better, so we are just not going to trust this one. But.. there is a very real possibility that we actually *do* know better than the issuing CA at this point. So, what exactly is the problem with accepting the remaining resources? i.e. the intersection between the parent certificate’s resources and this certificate. We know the context, this evaluation is very easy and well-defined. If the CA really intended that the remaining resources should not be tied to the certificate, they would have revoked. If the grand-parent really intended that those resources should not be certified anymore, they would have removed them as well.

I'm certain there is a simple answer for this question, but it alludes me
at the present time...

Given the risks of full resource list invalidation due to overclaiming, why
aren't distinct certificates used for distinct resources?  If this is not 
practical in general, wouldn't it at least be prudent to "groom" resources 
that are going to be transferred into their own certificate so that the rest 
of the resources held by the original child are not put at validation risk 
(if a coordination error were to occur in subsequent transfer processing)

Thanks!
/John

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 29 Oct 2014 11:44:22 -0300

Hi,

On 28/10/2014 20:17, John Curran wrote:
> ... snip ...

I believe you are right, in fact, I'm pretty sure, and I discussed this
with Mark a few weeks ago, that it's possible to get quite close to the
proposed semantics of validation-reconsidered just by separating
(grooming to use your term :-) ) resource sets accross different certs,
according to specific criteria.

This, to me, means that validation-reconsidered is actually is more like
an optimization proposal to something that could already be done today
iif we had HSMs able to support enough keys/certs. I'm convinced that
there isn't here a radical departure from the original spirit of
validation rules.

> /John

cheers!

-Carlos
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Geoff Huston <[email-masked]>
Date: Fri, 31 Oct 2014 02:59:34 +1100

> On 29 Oct 2014, at 10:17 am, John Curran <[email-masked]> wrote:
> 

If I understand your note here, you are suggesting that the CA issues a new cert for the to-be-transferred resource and revokes and reissues the original "omnibus" cert to have all the resources minus the to-be-transferred resource. Yes? But does not this exacerbate the very problem about over-claiming subordinate certs? Any subordinate certs of the shrunken "omnibus" cert that still include the to-be-transferred resource are now completely invalid. I may not be following your suggestion here, but I just can't see how this makes it "better".

regards,

Geoff

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 30 Oct 2014 19:38:39 +0100

Hi John, all,

Hoping to clarify my reasoning why I think this is validation approach provides a significant quick win..

On 29 Oct 2014, at 00:17, John Curran <[email-masked]> wrote:

> at the present time…

I would very much like to learn the answer to that question though, taken from above:
>> So, what exactly is the problem with accepting the remaining resources?

I believe we are rejecting ROAs or router certificates under strict rules for reasons that concern other objects. I just do not see a scenario where an RP could be led to accept a ROA or router certificate that *could* not be valid if strict rules are followed. The fix is higher in the chain. By claiming fewer resources, not more. And the exact same object would be considered valid.

If someone can come up with a scenario where a truly over claiming ROA or router certificate is considered valid under reconsidered rules, then I agree that it’s not option.

As it stands in my understanding though, this is an easy quick fix to limit the impact of problem of over claiming certificates to just *those* objects that refer to the resources.

So even if it then doesn’t solve those other issues, I believe we will have made a very significant improvement.

Tim

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 31 Oct 2014 17:06:17 -0400

speaking as regular ol' member

On Oct 30, 2014, at 11:59 AM, Geoff Huston <[email-masked]> wrote:

>>> …

To be honest, I get a bit confused as to whether we are considering the case of planned transfer actions, or some unanticipated reduction in a certificate's resources.

If we're talking about the planned case, then:
> 
> If I understand your note here, you are suggesting that the CA issues a new cert for the to-be-transferred resource and revokes and reissues the original "omnibus" cert to have all the resources minus the to-be-transferred resource. Yes?

Or, as another idea, leave the original certificate in place but also issue two certificates, one for the retained space, one for the transfer space.

If I'm planning on transferring some of my resources, I could request my parent do this.

If I have sub allocated some of those to-be-transferred resources to customers, then I'd be quite remiss if I were not mentioning this to my customer who was just about to lose some of their resources.  So maybe I'd reissue certs to customers who had exclusively retained space under the new cert with only retained space, same for the about to be transferred space.  The customers who have a mix of retained and transferred space are in a pickle of my own making, and I should work with them closely.  Before I do the transfer.

I think the RPKI structures work if I create the needed certs in the fate-sharing part of my customer cone.  (Maybe even a hint of gr**dp*r*ting).

I consider this similar to RIPE's instructions to their members to retain their authority over their sub allocated space, carefully setting the mtn-by, mtn-lower, mtn-route, etc..  Of course, that's from my reading of the RIPE documentation, so I could be wrong about that.

Working the process out for planned transfers would be valuable.

--Sandy, speaking as a regular ol' member

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 31 Oct 2014 17:49:42 -0400

speaking as regular ol' member.

>>> @1 The *grand*-parent shrinks the *parent* certificate without the parent knowing about this, and some of these resources appear on the, now overclaiming, child certificate. The grand-parent and…

If the removed resources re improperly removed, accepting the remaining resources does not help them.

I don't think this is an error case that we are trying to work out, here.  If we are trying to address that, we have a whole lot more solution space to explore.
 
>>> 
>>> If the CA really intended that the remaining resources should not be tied to the certificate, they would have revoked. 

Ironically, and no one has mentioned this much, but the CP says if a certificate's resources are reduced, the certificate with the original set is revoked.  

(Then a new certificate with the reduced set is issued with the same key.  I think that's weird.  There are people who think it is weird that I think it is weird.  :-)  )

I wonder sometimes if evaluating a ROA EE cert would find the new reduced certificate in the cache first or the issuing original certificate on the CRL first.

--Sandy, speaking as regular ol' member

---

From: Geoff Huston <[email-masked]>
Date: Sat, 1 Nov 2014 14:11:04 +1100

> On 1 Nov 2014, at 8:06 am, Sandra Murphy <[email-masked]> wrote:
> 

I'm sorry, but I don't understand how this ameliorates the issues in any way.

Now lets assume that the two new certificates are indeed "new" and neither "overwrites the "original certificate (with all its subordinate certs).

If that's the case then the CA now has to issue new subordinate certs using each of the new CA certificates - right? So will these subordinate certificates overwrite the existing subordinate certificates, or are they entirely new (new subject name, etc)? In the former case the problem of subordinate certificate overclaiming is still a possibility given that the CA cert used to issue these certificates is now missing the to-be-transferred resource, and in the latter case then each of these subordinate CAs has to in turn perform a full reissuance, which is a huge amount of ripple down work all the way to the end leaf points in the hierarchy.

Or, to quote from the draft document itself which describes pretty much exactly the case you are informally describing above:

   It is possible for the common registry to issue a certificate to the
   "sending" registry with the reduced resource set at any time, but it
   should not revoke the previously issued certificate, nor overwrite
   this previously issued certificate in its repository publication
   point without specific coordination.  Only when the common registry
   is assured that the top down certificate issuance process to the
   receiving registry CA chain has been completed can the common
   registry commence the revocation of the original certificate for the
   sending registry, However, it should not so until it is assured that
   the immediate subordinate registry CA in the path to the sending
   registry has issued a certificate with a reduced resource set, and so
   on.  This implies that on the sending side the certificate issuance
   and revocation is a "bottom up" process.

   If this process is not carefully followed, then the risk is that some
   or all or the subordinate certificates of this common registry CA
   will be unable to be validated until the entire process of
   certificate issuance and revocation has been completed.  While this
   sequenced process is intended to preserve validity of certificates in
   the RPKI, it is a complex, fragile and operationally cumbersome
   process..

   The underlying consideration here is that the operational
   coordination of these certificate issuance and revocation actions to
   effect a smooth resource transfer across registries is mandated by
   the nature of the particular choice of certificate validation process
   described in [RFC6487].

regards,

   Geoff