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

From: Andrei Robachevsky <[email-masked]>
Date: Tue, 1 Dec 2015 12:04:25 +0100

Tim Bruijnzeels wrote on 26/11/15 13:29:
> 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. 

Tim, I am not sure I understand this. If the parent of the EE cert has a
shrunken set of resources, will it invalidate the EE or only the
non-overlapping subset?

Andrei

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 1 Dec 2015 14:55:01 +0100

Hi Andrei

> On 01 Dec 2015, at 12:04, Andrei Robachevsky <[email-masked]> wrote:
> 

If the parent has a shrunken resource set this would lead to the EE certificate being accepted only for the intersection of its resources, and the parent. Because there is a requirement that all prefixes on a ROA are included (and accepted in reconsidered) in the resource set of the EE certificate the ROA will be considered invalid.

To avoid this it would be better to create one ROA per prefix and avoid fate sharing. That way only the ROA(s) for the prefix(es) that are no longer held by the (grand)parent(s) are affected.

Tim

---

From: Andrei Robachevsky <[email-masked]>
Date: Tue, 1 Dec 2015 15:42:13 +0100

> If the parent has a shrunken resource set this would lead to the EE certificate being accepted only for the intersection of its resources, and the parent. Because there is a requirement that all pr…

Thank you Tim, this makes sense. Otherwise we will be changing the
semantics of ROA, which is tricky. Could you please point me to the
place where the requirement is specified?

> To avoid this it would be better to create one ROA per prefix and avoid fate sharing. That way only the ROA(s) for the prefix(es) that are no longer held by the (grand)parent(s) are affected.

Right.

Thanks,

Andrei

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 1 Dec 2015 19:32:50 -0500

Speaking as regular ol’ member:

> place where the requirement is specified?

In RFC6483, page 5, section 4.  ROA Validation:

   o  The IP address delegation extension [RFC3779] is present in the
      end-entity (EE) certificate (contained within the ROA), and each
      IP address prefix(es) in the ROA is contained within the set of IP
      addresses specified by the EE certificate's IP address delegation
      extension.

Quibble.

In the current algorithm, the EE cert that mentioned some of the removed resources will be invalid.  That makes the ROA that mentioned some of the removed resources be invalid.

Under validation reconsidered, the EE cert will be valid, but not all the resources contained in it will be valid.  However, the EE cert still "contains" the removed resources, so the ROA “contained within” test would still succeed. So a ROA that mentioned some of the removed resources would still be considered valid. (I would say that’s bad.)

Under validation-reconsidered, we would need to make sure this section said something about the validity of the resources in the valid EE cert.

Just in case it is not obvious:

Suppose the EE cert always contained more resources than the ROA mentioned.

Suppose the ROA did not mention the resources that were removed.  In that case the shrinking of the parent causes a shrinking of the set of resources that are contained in the EE cert that are considered valid under validation-reconsidered.  The valid subset of the resources contained in the valid EE cert (i.e., the shrunken resources) would still cover the resources mentioned in the ROA.  So a ROA whose resources were contained exclusively within the retained resources would be valid.  (I would say that’s good.)

—Sandy, speaking as regular ol’ member

(We’ve overloaded “Valid” a couple of different ways valid certs, valid ROAs, valid origins, valid Signature_Blocks, …) - it might be nice to readers and users to come up with a different adjective here for the subset of the resources that are contained within the certificate, rather than yet another use of “valid”.   Before we have to talk about valid certs with invalid resources.)

---

From: Declan Ma <[email-masked]>
Date: Wed, 2 Dec 2015 11:18:04 +0800

> 在 2015年12月2日，08:32，Sandra Murphy <[email-masked]> 写道：
> 

Quite reasonable.

According to the discussions on Validation Reconsidered during the past few days, I think we need precise terminology. And documenting well-defined security problems is yet another critical thing. 

Di

---

From: Geoff Huston <[email-masked]>
Date: Wed, 2 Dec 2015 21:23:37 +1100

> On 2 Dec 2015, at 11:32 AM, Sandra Murphy <[email-masked]> wrote:
> 

RFC6482, section 4

> Under validation reconsidered, the EE cert will be valid, but not all the resources contained in it will be valid.  However, the EE cert still "contains" the removed resources, so the ROA “containe…

I’d say thats bad too.

So how about an example or two:

Example 1:

A CA Cert: 1.0.0.0/24, 2.0.0.0/24

issues:

B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24

issues:

C EE Cert: 1.0.0.0/24

and signs

ROA: 1.0.0.0/24 AS1

all good (assuming that A is a trust anchor)

Example 2:

A CA Cert: 1.0.0.0/24, 2.0.0.0/24

issues:

B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24

issues:

C EE Cert: 1.0.0.0/24, 2.0.0.0/24

and signs

ROA: 1.0.0.0/24 AS1

still all good (assuming that A is a trust anchor)

Example 3:

A CA Cert: 1.0.0.0/24, 2.0.0.0/24

issues:

B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24

issues:

C EE Cert: 1.0.0.0/24, 3.0.0.0/24

and signs

ROA: 1.0.0.0/24 AS1

still all good (assuming that A is a trust anchor)

Example 4:

A CA Cert: 1.0.0.0/24, 2.0.0.0/24

issues:

B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24

issues:

C EE Cert: 1.0.0.0/24, 3.0.0.0/24

and signs

ROA: 1.0.0.0/24, 3.0.0.0/24 AS1

invalid ROA

(or at least that’s my opinion of what should happen. My assumption here is that the ROA IS intentionally a collection of resources where the entirety of the collection is important, so if all elements of the collection cannot be validated via the ROA’s EE certificate then its a dud ROA.)

> Under validation-reconsidered, we would need to make sure this section said something about the validity of the resources in the valid EE cert.

I don’t think its a question of the EE cert, but the question of section 4 of RFC6482 and what validation of the ROA means.

> Suppose the EE cert always contained more resources than the ROA mentioned.

which is ok today under RFC6482

> Suppose the ROA did not mention the resources that were removed.  In that case the shrinking of the parent causes a shrinking of the set of resources that are contained in the EE cert that are cons…

i.e. thats like my example 3 above, so I agree thats good from where I sit as well.

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 2 Dec 2015 13:28:46 -0500

>>     addresses specified by the EE certificate's IP address delegation

Yep, my bad, that’s a typo, the quote is from RFC6482.  Sorry about that.

Attempt to be precise and miss a point.  Hate that.

> So how about an example or two:
<…>

> (or at least that’s my opinion of what should happen. My assumption here is that the ROA IS intentionally a collection of resources where the entirety of the collection is important, so if all elem…

That’s not my understanding of what the text currently says will happen.  Note that I am not disagreeing that this is the desired result.  (I did say “that’s bad”, above, remember.)

By my understanding of validation-reconsidered, the C EE cert would be valid but the valid resources in the valid C EE cert would be only 1.0.0.0/24.

The actual text of RFC6482 says that the “each IP address prefix(es) in the ROA is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension.”

Set 1: "each IP address prefix(es) in the ROA" :  1.0.0.0/24, 3.0.0.0/24 AS1

Set 2: "the set of IP addresses specified by the EE certificate's IP address delegation extension":  1.0.0.0/24, 3.0.0.0/24

is set1 contained within set2?  Yes.

So (under validation-reconsidered) the ROA meets the RFC6482 condition, as the text currently stands.  So the ROA would be valid.

> I don’t think its a question of the EE cert, but the question of section 4 of RFC6482 and what validation of the ROA means.

Under validation-reconsidered, I would say that the ROA should be valid if the IP addresses it contains are contained within the *valid* resources among the resources specified in the EE cert.

We need to say that because the valid resources specified in a valid EE cert could be a proper subset of the resources specified in the EE cert.  As your examples show.  Just “contained within” is not going to be sufficient specification.

No biggie, just a need for more precise text, under validation-reconsidered.

> i.e. thats like my example 3 above, so I agree thats good from where I sit as well.

Good, then I’ve got that much of validation-reconsidered right.

—Sandy

---

From: Geoff Huston <[email-masked]>
Date: Thu, 3 Dec 2015 07:49:17 +1100

> On 3 Dec 2015, at 5:28 AM, Sandra Murphy <[email-masked]> wrote:
> 
> 

I do it all the time. sigh.

> So (under validation-reconsidered) the ROA meets the RFC6482 condition, as the text currently stands.  So the ROA would be valid.

That’s a good point, and in my world that’s not the desired outcome. Which implies that a revision of the validation algorithm should have something to say about the set of number resources in an EE certificate that can be considered  - informally each of the “good” resources in an EE cert must be present in each of the CA certs in the validation path. And secondly it should specifically consider ROAs, and possibly considere the more generic case and consider whether the “bundle” of resources is a critical element of the signed attestation. My intuitive reaction is that a ROA is an “all or nothing” prospect, so you can’t have a valid ROA with a subset of INRs listed in the ROA, but others may see it differently.

> No biggie, just a need for more precise text, under validation-reconsidered.

agreed by me at any rate.

> Good, then I’ve got that much of validation-reconsidered right.

Its a good point, however, and I hope its been useful to consider in this way.

regards,

   Geoff

---

From: Declan Ma <[email-masked]>
Date: Thu, 3 Dec 2015 14:24:32 +0800

> 在 2015年12月2日，18:23，Geoff Huston <[email-masked]> 写道：
> 
> 
> 
> Example 2:
> 

Geoff,

In section 2.3 of RFC 6480, the very text says:

For ROAs and manifests, there will be a one-to-one correspondence
   between end-entity certificates and signed objects, i.e., the private
   key corresponding to each end-entity certificate is used to sign
   exactly one object, and each object is signed with only one key.

Due to the so-called one-to-one, why bother to create an EE cert that has more INR than its corresponding ROA?

Sorta confused.

Di

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

---

From: Geoff Huston <[email-masked]>
Date: Thu, 3 Dec 2015 17:32:47 +1100

> On 3 Dec 2015, at 5:24 PM, Declan Ma <[email-masked]> wrote:
> 
> 
> 
> 
> 

I have no idea why either - but - the specs don’t say that the resources listed in the EE cert must exactly match the
resources in the ROA, so its possible for the EE cert to have a larger number resource set than the ROA.

regards,

   Geoff

---

From: Declan Ma <[email-masked]>
Date: Thu, 3 Dec 2015 14:41:00 +0800

> 在 2015年12月3日，14:32，Geoff Huston <[email-masked]> 写道：
> 
> 

Indeed.

I am fine with this.

Di,

---

From: Andrei Robachevsky <[email-masked]>
Date: Thu, 3 Dec 2015 10:20:32 +0100

> No biggie, just a need for more precise text, under validation-reconsidered.

Agree, the validation reconsidered will require a more precise
definition in RFC6482, something like:

The IP address delegation extension [RFC3779] is present in the
end-entity (EE) certificate (contained within the ROA), and the whole
collection of IP address prefix(es) in the ROA is contained within the
set of IP addresses specified by the EE certificate's IP address
delegation extension that are valid according to the
[validation-reconsidered] checks.

There might be other places that may read ambiguously in light of
validation reconsidered. The thing is that we now have a bunch of
validity concepts: a valid certificate, a valid resource within an
extension of a valid certificate, a valid ROA (and we do not extent this
further to a valid resource within a ROA).

Andrei

---

From: Karen Seo <[email-masked]>
Date: Mon, 7 Dec 2015 18:55:23 -0500

Just fyi... Steve was out of the country last week and this.  He should 
be back next week...

On 11/25/15 8:11 PM, Geoff Huston wrote:
> 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
>>
>>
>> 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.
> 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)
>
>
>> Now, under the assumption about what "specific resource set" means, when
>> 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
>> 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.
>
> 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.
>
>
>> 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,
> 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: Stephen Kent <[email-masked]>
Date: Thu, 17 Dec 2015 11:27:29 -0500

Tim,
> ...
> 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.
That's a reasonable goal, but it does not match what the revised 
algorithm says.
> 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."
The recommendation you cite belongs in an updated ROA spec.
> Essentially that really is all there is to it.
I'm afraid it's not that simple. The statement of what you want to 
accomplish
does not match the algorithm described in Section 5, and that is my 
point, i.e.,
the revised algorithm is not correct.
> 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.
As I noted above, the algorithm description in Section 5 doesn't match what
you say you want to accomplish. Below is my take on what a revised 
validation
algorithm should say to implement what you and your co-authors seem to 
want to accomplish. You'll note that it is substantially different from 
the text
that appears in the current I-D.

Steve

------

7.2.Resource Certification Path Validation

The following algorithm is employed to validate CA and EE resources 
certificates. It is modeled on the path validation algorithm from 
[RFC5280], but modified to make use of the IP Address Delegation and AS

Identifier Delegation Extensions from [RFC3779].

There are two inputs to the validation algorithm:

1.a trust anchor

2.a certificate to be validated

The algorithm is initialized with the following new variables:

1.If an IP Address Delegation extension is present in the trust anchor 
the address set flag is initialized to TRUE and the address resource 
working set is initialized to the value of this extension. If the 
extension is absent, the flag is initialized to FALSE and the address 
resource working set is initialized to NULL.

2.If an AS Identifier Delegation extension is present in the trust 
anchor, the AS number flag is initialized to TRUE and the AS number 
resource working set is initialized to the value of this extension. If 
the extension is absent, the flag is initialized to FALSE and the AS 
number working set is initialized to NULL.

This path validation algorithm verifies, among other things, that a

prospective certification path (a sequence of n certificates)

satisfies the following conditions:

A.for all 'x' in {1, ..., n-1}, the subject of certificate 'x'

is the issuer of certificate ('x' + 1);

B.certificate '1' is issued by a trust anchor;

C.certificate 'n' is the certificate to be validated; and

D.for all 'x' in {1, ..., n}, certificate 'x' is valid.

Certificate validation requires verifying that all of the following

conditions hold, in addition to the certification path validation

criteria specified in Section 6 of [RFC5280].

1.The signature of certificate x is verified using the

public key of the issuer’s certificate (x-1), using the

signature algorithm specified for that public key (in

certificate x-1).

2.The current time lies within the interval defined by the

NotBefore and NotAfter values in the Validity field of

certificate x.

3.The Version, Issuer, and Subject fields of certificate x

satisfy the constraints established in Section 4.1-4.7

of this specification.

4.Certificate x contains all the extensions that MUST be

present, as defined in Section 4.8 of this specification.

The value(s) for each of these extensions MUST be satisfy

the constraints established for each extension in the

respective sections.

5.Any extension not identified in Section 4.8 MUST NOT

appear in certificate x.

5.Certificate x MUST NOT have been revoked, i.e., it

MUST NOT appear on a CRL issued by the CA represented by certificate x-1

6.Compute the address space and the AS number working sets
and flags values for certificate x as follows:

If the IP Address Delegation extension is present

in certificate x, and the address flag is TRUE, then

compute the intersection of the resources between this

extension and the current value of the address

space working set.

If the IP Address Delegation extension is present

in certificate x, and the address flag is FALSE,

the certificate fails validation.

If the IP Address Delegation extension is absent

in certificate x, set the address set flag to FALSE.

If the AS Identifier Delegation extension is present

in certificate x, and the AS number flag is TRUE, then

compute the intersection of the resources between this

extension and the current value of the address

space working set.

If the AS Identifier Delegation extension is present

in certificate x, and the AS number flag is FALSE,

the certificate fails validation.

If the AS Identifier Delegation extension is absent

in certificate x, set the AS number flag to FALSE.

If x = n (i.e., this is the certificate being validated)

then the IP address space and AS number working sets are

treated as the values for the IP Address and AS Identifier Delegation 
extensions for this certificate, respectively.

If an RP is caching the results of validation, these values

SHOULD be stored along with the certificate, to facilitate

incremental validation based on cached results.

Otherwise, return to step 1 and continue path validation.

These rules allow a CA certificate to contain resources

that are not present in (all of) the certificates along

the path from the trust anchor to the CA certificate.

(If none of the resources in the CA certificate are present

in all certificates along the path, no subordinate

certificates could be valid. However, the certificate is not immediately 
rejected as this may be a transient condition.

Not immediately rejected the certificate does not result in a security 
problem because the associated working resource sets accurately reflect 
the resources associated with the

certificate in question.)

The address and/or AS number resources contained in a

valid EE certificate being validated MUST always be

encompassed by all certificates along the path to the

trust anchor (used to verify that EE certificate). Also

note that if any CA certificate along the path has no

address space resources, then any subordinate certificate

MUST NOT contain address space resources. The same constraint applies to 
AS number resources.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 18 Dec 2015 10:04:39 +0100

Hi Steve,

Without going into every detail.

I understand this is not what the current text says. I provided an alternative description to illustrate how I would propose to re-write text. The current text takes a bottom-up view of the process w.r.t. verifying the presence of resources looking back up the path for a given certificate or object. I believe things are much more clear taking a top-down view.

I hope to find time over the next weeks to do this work and would welcome your feedback on new text when it is done.

Tim

> On 17 Dec 2015, at 17:27, Stephen Kent <[email-masked]> wrote:
> 
> Tim,
>> ...
> That's a reasonable goal, but it does not match what the revised algorithm says.
> I'm afraid it's not that simple. The statement of what you want to accomplish 
> does not match the algorithm described in Section 5, and that is my point, i.e.,
> you say you want to accomplish. Below is my take on what a revised validation 
> algorithm should say to implement what you and your co-authors seem to want to accomplish. You'll note that it is substantially  different from the text
> 7.2.  Resource Certification Path Validation
>  
> The following algorithm is employed to validate CA and EE resources certificates. It is modeled on the path validation algorithm from [RFC5280], but modified to make use of the IP Address Delegation and AS
> 1.  a trust anchor 
> 2.  a certificate to be validated
>  
> 1. If an IP Address Delegation extension is present in the trust anchor the address set flag is initialized to TRUE and the address resource working set is initialized to the value of this extension. If the extension is absent, the flag is initialized to FALSE and the address resource working set is initialized to NULL.
>  
> 2. If an AS Identifier Delegation extension is present in the trust anchor, the AS number flag is initialized to TRUE and the AS number resource working set is initialized to the value of this extension. If the extension is absent, the flag is initialized to FALSE and the AS number working set is initialized to NULL.
>  
>  
>       A.  for all 'x' in {1, ..., n-1}, the subject of certificate 'x'
>       B.  certificate '1' is issued by a trust anchor;
>  
>       C.  certificate 'n' is the certificate to be validated; and
>  
>       D.  for all 'x' in {1, ..., n}, certificate 'x' is valid.
>  
> 1.      The signature of certificate x is verified using the 
> 2.  The current time lies within the interval defined by the 
> 3.  The Version, Issuer, and Subject fields of certificate x 
> 4.  Certificate x contains all the extensions that MUST be 
>       5. Any extension not identified in Section 4.8 MUST NOT
>          appear in certificate x.
>  
> 5.  Certificate x MUST NOT have been revoked, i.e., it 
> 6.  Compute the address space and the AS number working sets
> treated as the values for the IP Address and AS Identifier Delegation extensions for this certificate, respectively. 
> certificates could be valid. However, the certificate is not immediately rejected as this may be a transient condition. 
> Not immediately rejected the certificate does not result in a security problem because the associated working resource sets accurately reflect the resources associated with the 
> MUST NOT contain address space resources. The same constraint applies to AS number resources. 
>  
> 
>