Subject: Re: [sidr] Validation Reconsidered (again/again) question

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Nov 2015 15:19:52 -0500

None of those who believe that this draft is a good thing seem to have 
addressed
an issue I raised a while ago; the proposed solution is ill-defined and, 
the most
likely interpretation doesn't seem to work, in general. I'll try to 
explain this
reasoning, again, and provide an example.

Section 2 of the I-D says:

    Validation of signed resource data using a target resource

certificate, and a specific set of number resources, consists of

verifying that the digital signature of the signed resource data is

valid, using the public key of the target resource certificate, and

also validating the resource certificate in the context of the RPKI,
    using the path validation process.

Personally, I have trouble understanding what that 5 1/2 line sentence 
means,
in no small part because the phrase "signed resource data" is not defined
anywhere in the I-D. The text that follows reproduces, with one 
exception, the
path validation description from 6487, so I assume that the text is 
proposing
a change to that path validation process.
PowerPoint Presentation
The one change made to the path validation procedure in RFC 6487 arises
in step 6, which is reworded to be:

The resource extension data contained in this certificate

"encompasses" the entirety of the resources in the specific

resource set ("encompass" in this context is defined in

Section 7.1 of [RFC6487]).

PowerPoint Presentation

PowerPoint Presentation As I noted before, the phrase "_specific_ 
resource set" is undefined in the I-D.
I'm guessing that many folks believe this term refers to any address 
space and ASN
extensions in the cert being validated. That's a simple, reasonable 
interpretation
of the text, and the authors have not stated a different intent, so 
let's proceed
on that assumption. Consider the following example that, WLOG, focuses 
only on
address space.

Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE cert 
for a ROA.

TA->CA 1->CA 2->ROA

Assume the TA cert contains address space T, U, V, W, X, Y and Z.

Assume the CA 1 cert contains address space T, U, V, and W.

Assume the CA 2 cert contains address space V and W.

Let's say that the ROA EE cert issued by CA 2 contains address space V.

CA 2 is about to receive address space Z from some other ISP, so it has 
asked
CA 1 to issue a new CA cert to it, in anticipation of the transfer. CA 1 
agrees,
and issues a new cert to CA 2 and that cert contains address space V and Z.

Now, under the assumption about what "specific resource set" means, when
an RP tries to validate CA 2's ROA, the "specific resource set" will be 
V, and
so it will be valid, because V is in all of the certs from the TA 
through CA 1
to CA 2. Even though CA 2's cert contains Z, which is not contained
in CA 1's cert, this will not be considered in the validation of the ROA 
EE cert.
This is the desired outcome, because CA 2 has begun the process of 
getting its
new address space (Z), but that process has not broken its CA cert. I 
assume this
is an example of the reduced fragility that is so appealing.

If CA 2 issued a ROA for Z, then validation of that ROA would fail, because
the CA 1  cert does not contain Z. That's good, because the second ROA 
exmaple
ought not be valid, since the transfer has not yet completed.

So far, so good. But, let's look at the implications of this revised 
validation
procedure in greater depth.

What if CA 1, acting on the request from CA 2 asked the TA to add Z to 
CA 2's cert,
in anticipation of the transfer? Then we have a problem, because Z is 
under the
tree from this TA and if it agreed to add Z to CA 1's cert, then a ROA 
for Z,
issued by CA 2, would be valid, even though the transfer had not yet 
been effected.

So, when folks claim that this alg allows for transfers to not have to 
follow
a strict ordering of RPKI actions, that is only partly true. Issuing a 
new CA
cert with resources not yet transferred to the target can actually 
enable the
target to generate bogus ROAs that will validate, unless certain precautions
are taken. Every CA has to be sure that IF it issues a cert to a 
subordinate
because of an anticipated transfer, that this act does not enable the 
subordinate
(or a child of the subordinate ...) to issue bogus ROAs! Right now we 
have no
agreed-upon resource transfer process for the RPKI, to ensure that this 
sort of
vulnerability does not arise. Yet the suggestion is to change the 
validation
procedure before having such a process in place. Not such a good idea.

A bigger problem, IMHO, is that if an RP validates CA 2's (new) cert,
the "specific resource set" will be V and Z (according to the interpretation
cited above). However, using the revised step 6, validation will fail,
because CA 1's cert does not contain Z. To avoid this problem, RPs would 
have
to not validate CA certs that might contain address space that is not 
present
in _all_ the certs along the path.

This is a bad outcome, for two reasons. An RP should validate each CA 
cert it
fetches, to minimize opportunities for DoS attacks.  An RP also should 
be able
to maintain a local cache where it need not walk the whole path to a TA 
every time
a new cert (of any type) appears. Note, for example, that new manifest 
certs
are issued daily. So, if one tries to take advantage of the reduced 
fragility
promised by this change to step 6, a CA cert with resources not present 
in all
if its parent certs will fal validation anyway. Not such a great outcome.

Also recall that new CRLs tend to be issued at least daily. To validate 
a CRL
an RP uses the public key from the CA cert under which the CRL was 
issued. That
implies the RP has validated the CA cert before using the public key 
from it.
Yet, as noted above, if the CA cert has address space not contained in 
all of its
parents, that cert will be invalid. So, RPs would have to treat CRL 
validation
as a special case, using a public key from a CA cert that has not been 
validated
relative to the revised process, to avoid this problem. Again, I see this as
not a great outcome, as it introduces additional complexity into the 
validation
process.

The bottom line is that the revised path validation algorithm, as 
(ill-)defined,
does not work the way many folks seem to believe. I fear folks have a 
vague notion
about what the revised validation algorithm is, and they like the 
benefits it
claims to offer, but they have not examined in detail exactly what the 
I-D says
and what that means in practice. That's why I suggest that the new 
editors of
the I-D need to revise it, address the ambiguities, and then the WG can 
decide
whether the resulting document is worth pursuing.

Happy turkey day,

Steve

---

From: Geoff Huston <[email-masked]>
Date: Thu, 26 Nov 2015 12:11:36 +1100

Hi,

I’m working through this example and I can’t help but observe that its
"ill-defined and, the most likely interpretation doesn't seem to work”
to borrow your words….

> 
> Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE cert for a ROA.
> 
> TA->CA 1->CA 2->ROA
> 
> 
> CA 2 is about to receive address space Z from some other ISP, so it has asked 
> CA 1 to issue a new CA cert to it, in anticipation of the transfer. CA 1 agrees, 

CA1 has already issued a cert with subject “CA2” and resources (V,W) - lets call this cert No 1

Do you mean: 

a) CA 1 issues a cert  with subject “CA2” and resources (V,Z) - lets call this cert No 2

OR the combination of actions:

b)    CA 1 issues a SECOND cert  with subject “CA2” and resources (V,Z)  - lets call this Cert No 2
   AND
      CA1 revokes the cert with subject “CA2” and resources (V,W) (which we call Cert No 1)

> an RP tries to validate CA 2's ROA,

Now I’m confused - originally the ROA was signed by an EE cert issued by CA 2’s Cert No 1

so when you refer to CA 2’s ROA do you mean the ROA that was signed by an EE cert issued by CA 2’s Cert No 1,
or do you mean a new ROA signed by an EE issued by CA 2’s Cert No 2?

> the "specific resource set" will be V, and
> so it will be valid, because V is in all of the certs from the TA through CA 1
> in CA 1's cert, this will not be considered in the validation of the ROA EE cert.
> This is the desired outcome, because CA 2 has begun the process of getting its 
> new address space (Z), but that process has not broken its CA cert. I assume this

So I _think_ you are assuming that there is a new ROA, signed by an EE cert issued by 
the CA that has a CA cert issued by CA 1 with resources (V,Z), and evidently you are referring
to this new ROA and its new EE cert.

> the CA 1  cert does not contain Z. That's good, because the second ROA exmaple
> So far, so good. But, let's look at the implications of this revised validation 
> What if CA 1, acting on the request from CA 2 asked the TA to add Z to CA 2's cert,

Huh?????

The TA has issued a cert for subject “CA 1” - Since when did Ca2 have a relationship
with the TA?

>  
> in anticipation of the transfer? Then we have a problem, because Z is under the 
> tree from this TA and if it agreed to add Z to CA 1's cert, then a ROA for Z, 
> issued by CA 2, would be valid, even though the transfer had not yet been effected.

I’m having trouble following this - I think you have a typo of otherwise confused
the example at this point.

I’ll stop here because I can’t see the point of the ensuring text without some additional
clarity and precision of the example scenario that does not invent arbitrary relationships
between CAs.

regards,

   Geoff

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 26 Nov 2015 13:29:51 +0100

Hi,

> On 25 Nov 2015, at 21:19, Stephen Kent <[email-masked]> wrote:
> 
> None of those who believe that this draft is a good thing seem to have addressed
> an issue I raised a while ago; the proposed solution is ill-defined and, the most
> likely interpretation doesn't seem to work, in general. I'll try to explain this

I believe the draft is being precise, but in the process has become difficult to parse. Let me attempt once more to explain the proposal in a different way:

"When doing top-down validation of resource certificates in the RPKI we propose that rather than rejecting a certificate that has resources not held by the parent (but is valid on all other respects), we would accept the certificate but keep note of the actual resources we believe it can be authoritative for. I.e. the intersection of resources on this certificate and the resources accepted for the parent. The RP SHOULD however issue a warning in case certain resources are excluded because of this, so that the responsible CA can fix the situation.

Please note that for ROAs there is a requirement that all ROA prefixes are included on the EE certificate of the (ROA) signed object CMS. This proposal does not change this. A ROA that has prefixes that were removed for whatever reason higher in the path would still become invalid using this algorithm. We would therefore RECOMMEND that CAs issue 1 ROA for each prefix, and avoid fate sharing. That way only ROAs for prefixes that were removed will be affected."

Essentially that really is all there is to it. If this is easier to parse, and the co-chairs conclude that work should continue, then I am happy to use this line of explanation in a next version of the document. And no, I have no doubt that it will need more detail than above in an I-D - but it's the basic principle that I am trying to convey here.

Tim

---

From: Declan Ma <[email-masked]>
Date: Thu, 26 Nov 2015 21:33:36 +0800

Tim,

Thanks for your explanations.

Yet since the very draft keeps talking about Resource Transfer and deems it as one of the  “Operational Considerations” in Section 3, we might pay attention to Steve’s statement as below: 

So, when folks claim that this alg allows for transfers to not have to follow 
a strict ordering of RPKI actions, that is only partly true. Issuing a new CA
cert with resources not yet transferred to the target can actually enable the
target to generate bogus ROAs that will validate, unless certain precautions
are taken. Every CA has to be sure that IF it issues a cert to a subordinate 
because of an anticipated transfer, that this act does not enable the subordinate
(or a child of the subordinate ...) to issue bogus ROAs! Right now we have no 
agreed-upon resource transfer process for the RPKI, to ensure that this sort of
vulnerability does not arise. Yet the suggestion is to change the validation 
procedure before having such a process in place. Not such a good idea.

As Randy’s draft relating to Resource Transfer is still in progress, it would be not wise to seek solutions to the so-called fragility in validating certificates when we have no agreed-upon resource transfer process for the RPKI. 

Di

> 在 2015年11月26日，20:29，Tim Bruijnzeels <[email-masked]> 写道：
> 
> Hi,
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Geoff Huston <[email-masked]>
Date: Fri, 27 Nov 2015 06:36:40 +1100

Declan,

I’d pay more attention to this statement you are quoting if and only if the
justification for this statement made any sense. As far as I can tell the
example used to build to this point is confused and imprecise, so its a
leap of faith that I’m not perform to then hold the conclusions as valid.

I find it equally challenging to then reach the conclusion that you appear to be
providing that that somehow all this is dependant on a draft relating to certificate
mediated resource transfer. Again I see what appears to be another leap of faith 
going on here.

Geoff

> On 27 Nov 2015, at 12:33 AM, Declan Ma <[email-masked]> wrote:
> 
> Tim,
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Nov 2015 07:39:54 -0800

> I find it equally challenging to then reach the conclusion that you
> appear to be providing that that somehow all this is dependant on a
> draft relating to certificate mediated resource transfer. Again I see
> what appears to be another leap of faith going on here.

well, not that i makes a lot of difference, but my memory is somewhat
otherwise.  i thought we kind of agreed that we needed to better
understand transfer before we know the constraints and features needed
both in validation reconsidered and the stuff steve is pushing.  but my
memory is not all that i might desire.

randy

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 27 Nov 2015 23:52:38 +0000

Tim,

Your explanation does lay it out more clearly, and it is consistent with how I understood it before.
However, I have two questions/suggestions:

1.  A question/suggestion about the new validation algorithm:

Consider the following cert-chain, ROA example:

TA: {5.0.0.0/8, 8.0.0.0/12, AS1-AS100}
CA1: {5.0.0.0/20, 8.0.0.0/18, AS1-AS400}
CA2: {5.0.0.0/24, 8.0.0.0/20, AS1-AS50}   <-- note the "narrowing" of sub-cone in the 5.0.0.0/x space 
CA3: {5.0.0.0/22, 8.0.0.0/22, AS1-AS500}  <-- note the "widening" of sub-cone in the 5.0.0.0/x space 
CA4: {5.0.0.0/24, 8.0.0.0/24, AS1-AS5}

(Hint: picture specific-resource sub-cones within the broader cone of varied resources)

The EE certs are:
EE1: {5.0.0.0/24} generated from CA4
EE2: {8.0.0.0/24} generated from CA4

And the ROAs are:
ROA1: {5.0.0.0/24, AS1000}  (signed with EE1) 
ROA2: {8.0.0.0/24, AS2000}  (signed with EE2)

I think your proposed validation algorithm would determine that
EE1, EE2, ROA1 and ROA2 are all valid.
However, if you require that the specific resource (e.g. 5.0.0.0/24) -- that is relevant
to the ROA or the EE cert being validated -- MUST have a “non-narrowing sub-cone” 
in the cert chain resources, then EE2 and RAO2 will be still valid, 
but EE1 and ROA1 will be invalid. 
By “non-narrowing sub-cone” (for a specific resource/prefix), I mean the following: 
As we move up the cert-chain, the “relevant” or “corresponding” 
prefixes (relative to the specific prefix in consideration) seen at each level 
in the hierarchy of certs must be such that the same prefix or a less specific 
is found at each level relative to the level directly below.
As you can see in the example, non-narrowing sub-cone is true for 8.0.0.0/24 (EE2),
but not for 5.0.0.0/24 (EE1). Hence, EE1 and ROA1 are invalid (under this enhancement).
Do you think there merit in this approach over what you have now in validation reconsidered? 
This somewhat less lenient approach would seem a bit more sensible (at least in my mind).

2. How do you perform the validation of a CRL?
How is it similar to or different from how you validate a ROA?
How do you walk the certificate hierarchy in the case of a CRL validation process?
I.e. How are the "encompassing" rules applied?
I think this should be explicitly explained/clarified in the document.

Sriram  

________________________________________
From: sidr <[email-masked]> on behalf of Tim Bruijnzeels <[email-masked]>
Sent: Thursday, November 26, 2015 7:29 AM
To: Stephen Kent
Cc: sidr
Subject: Re: [sidr] Validation Reconsidered (again/again) question

Hi,

Tim

---

From: Geoff Huston <[email-masked]>
Date: Mon, 30 Nov 2015 06:37:26 +1100

Hi Sriram,

> On 28 Nov 2015, at 10:52 AM, Sriram, Kotikalapudi <[email-masked]> wrote:
> 
> Tim,
> 

yes in both cases

> This somewhat less lenient approach would seem a bit more sensible (at least in my mind).

qualitative judgment: no, not in my view

> 2. How do you perform the validation of a CRL?

RFC6487 provided no guidance, and referred to RFC5280, so that is still the case.
nothing changes herre.

> How is it similar to or different from how you validate a ROA?

There are no resources in a CRL so I presume that section 6.1 of RFC5280 is
a good procedure to follow.

> I.e. How are the "encompassing" rules applied?

huh - I’ll say it again just to be sure: CRLs have no resources.

> I think this should be explicitly explained/clarified in the document.

I disagree.

Geoff

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sun, 29 Nov 2015 21:58:02 +0000

Geoff,

Thanks for your responses. Please see below for my further comments.

>huh - I’ll say it again just to be sure: CRLs have no resources.

But what about the CA certificate under which the CRL was issued? 
That certificate has resources in it.
Don't you need to validate that certificate before you validate the CRL?
Does the RP apply the revised (lenient) algorithm in that validation process as well?
Or, does the RP need to use two separate validation algorithms -- 
(1) the revised (lenient encompassing) algorithm for ROAs (or EE certs), and
(2) the existing (strict encompassing) algorithm elsewhere?

After re-reading Steve Kent's post, I realize that he asked a similar question earlier:
http://www.ietf.org/mail-archive/web/sidr/current/msg07442.html 
(Please see his 3rd last paragraph -- about CRLs)

Sriram

---

From: Geoff Huston <[email-masked]>
Date: Mon, 30 Nov 2015 10:00:57 +1100

> On 30 Nov 2015, at 8:58 AM, Sriram, Kotikalapudi <[email-masked]> wrote:
> 
> Geoff,
> 

I would’ve thought that if you can establish a chain of Issuer / subject certs that
connect a chosen Trust Anchor to the CA that issued the CRL then you have a sound reason to
accept the CRL. Given that the CRL has no resources there does not seem to be any
resource attribute test that can be applied here.

Geoff