Subject: Re: [Sidr] Multiple Signatures on a ROA: Proposal

From: Sandra Murphy <[email-masked]>
Date: Tue, 19 Feb 2008 18:23:06 -0500 (Eastern Standard Time)

There was a lot of comment at the mike at the last IETF about the proposal 
to allow multiple signatures on a ROA.  Matt volunteered to provide a
discussion requested at the mike.

His message came out a month ago, and there have been no comments on  his 
message.

This issue needs to be settled so we can proceed.  So please pay 
attention, folks.

To hopefully start things off, I have a few comments, maybe enticing you 
all go take a look at what was written on Jan 17.

--Sandy

On Thu, 17 Jan 2008, Matt Lepinski wrote:

> At IETF 70, Geoff and I agreed to put together a concrete proposal for how 
> multiple signatures on a ROA would work.
>
> The attached file outlines our proposed changes to 
> draft-ietf-sidr-roa-format.
>
> Comments, suggestions or clarifying questions would greatly appreciated. 
> - Matt Lepinski
>

(Commenting as a wg member, not wg chair)

>The proposed solution is to alter the ROA format to allow for a ROA that
>includes signatures from multiple signers. In essence, this provides a
>way for a subject of the certificate containing 10.0/16 to state "I, as
>the owner of 10.0/16, authorize AS 123 to advertise the aggregate prefix
>10.0/15".

I think I'd quibble about the wording here.  The owner of just 10.0/16 can 
not in this format authorize the origination of the aggregate.  (And be 
careful of the word "owner" :-))  It is the "owner" of both parts of the 
aggregate who is authorizing the origination of the aggregate.  So maybe 
"I, as the holder (:-)) of 10.0/16 and 10.1/16, authorize AS 123 ...." 
would work better.

>                  By now mandating support for multiple SignerInfo
>objects, we ensure that such a future hash function migration can be
>performed in a backwards compatible fashion.

Good point.  I hadn't realized that about the SignerInfo.  (But see
below.)

>                                            In the degenerate case where
>there are multiple signatures that correspond to the same address range,
>then the authorization is only considered valid if all signatures are
>valid.

I would think that this would be the case for any ROA, not just the
degenerate case.  (I think you are just trying to point out that using
multiple signatures with overlapping ranges does not make it more likely
that the ROA validation will succeed.)

But if so, what happens if in the case of multiple hash algorithm
signatures - would not one of them be likely to fail, invalidating the 
ROA?  (unless the recipient supported both hash algorithms)

>The instructions for ROA validation in Section 3 of draft-ietf-sidr-roa-
>format would then be changed to the following:

I think that the comments at the last meeting specifically asked for
discussion of the error cases, which aren't addressed in what follows.

>   	2.B Use the public key in the EE certificate to verify the
>   	    signature on the ROA.

If a signature does not validate, then the loop is terminated at that
point, because that constitutes failure of the ROA verification, right?

Even if the all remaining signatures validate and cover the aggregate?

>   	2.C Verify that the EE certificate is a valid end-entity
>   	    certificate in the resource PKI by constructing a valid
>   	    certificate path to a trust anchor. (See
>   	    draft-ietf-sidr-res-certs for more details.)

Do all the signatures have to be validated with EE certificates that can
be traced to the *same* trust anchor?

(I would think not, but that question came to mind.  Someone pointed out
on the list (George Michaelson, I think) that due to the ERX transfer of
addresses between RIRs, there are some sequences of aggregatable
addresses that are not in the same RIR.  A ROA with such an aggregate
address might potentially have certificate paths that ended in separate
trust anchors.  Depending on how the root of the RPKI ends up being
handled.)

>   3. Compute the union of addresses in the list of prefixes
>      corresponding to verified signatures by aggregating adjacent
>      prefixes to the greatest possible extent. If this union exactly
>      matches the IP address prefix(es) in the ROA, then the ROA is
>      valid.

Exactly matches?  A covering match will not suffice?

>Note on the additional complexity introduced by this proposal:
>...
>                                                       Additionally,
>this proposal requires an implementation to create a list of prefixes
>and then aggregate the prefixes to the greatest possible extent.

No words here on how complex that code would be.  I presume no problem.

--Sandy

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

---

From: Matt Lepinski <[email-masked]>
Date: Mon, 25 Feb 2008 11:07:37 -0500

Sandy,

Thanks a lot for the comments.

Let me first introduce the (informal) terminology that a signature on a 
ROA is "GOOD" if it can be verified using an EE certificate that is 
valid (according to the draft-ietf-sidr-res-certs), and the signature is 
"BAD" otherwise.

Then when validating a ROA there seem to be the following cases:
A) All signatures on a ROA are "BAD"
B) All signatures on the ROA are "GOOD", but the ROA contains an IP 
address prefix that is not covered by a "GOOD" signature
C) The ROA contains both "GOOD" and "BAD" signatures, but the ROA 
contains an IP address prefix that is not covered by a "GOOD" signature
D) The ROA contains both "GOOD" and "BAD" signatrues, and all IP address 
prefixes in the ROA are covered by a "GOOD" signature
E) All signatures on the ROA are "GOOD", and all IP address prefixes in 
the ROA are covered by a "GOOD" signature

In cases A, B and C, the ROA is declared invalid. (Invalid ROAs should 
be handled in the same way regardless of which case they fall under)

In case E, the ROA is declared valid.

As you indicate in your comments, the proposal was unclear as to the 
handling of ROAs in case D. Personally, I believe that the proposal is 
reasonable whether Case-D ROAs are deemed valid or invalid. If Case-D 
ROAs are deemed valid, then there is a possibility for a 
backwards-compatible mechanism for hash-function migration (if needed in 
the future). However, it is possible that Case-D ROAs should be deemed 
invalid to improve safety or to reduce complexity.

Please let me know if there are other cases that I have missed which 
need to be clarified.

<additional comments inline below>

> I think I'd quibble about the wording here.  The owner of just 10.0/16 
> can not in this format authorize the origination of the aggregate.  
> (And be careful of the word "owner" :-))  It is the "owner" of both 
> parts of the aggregate who is authorizing the origination of the 
> aggregate.  So maybe "I, as the holder (:-)) of 10.0/16 and 10.1/16, 
> authorize AS 123 ...." would work better.
>
I completely agree that "owner" was a poor choice of words. Also, upon 
re-reading I realize that the quoted informal text doesn't really say 
what I want it to say.

The important thing is that everyone understands the proposal at a high 
level. In essence, we are giving the holder of 10.0/16 a mechanism to 
give concent for AS 123 to originate the aggregate prefix. If both the 
holder of 10.0/16 and the holder of 10.1/16 give concent (by each 
signing the ROA) then the ROA is valid and authorizes AS 123 to orginate 
the aggregate prefix.

> ROA?  (unless the recipient supported both hash algorithms)
Clearly I suggested that this mechanism might be used for hash function 
migration without fully thinking through the ramifications.

On the question of how to handle the case where a particular IP address 
prefix is covered by two signatures (one valid and one invalid), I think 
the working group could reasonably go either way.

Allowing validation to succeed when a particular prefix is covered by 
two signatures (one valid and one invalid) provides a possible 
backwards-compatible mechanism for future hash function migration. 
However, perhaps it is safer (or less complex to implement?) to mandate 
that validation fail in the case where any signature on the ROA cannot 
be verified.

Alternatively, we could differentiate between the following two cases of 
signature verification failure: (1) Verification fails because of an 
unsupported algorithm; vs (2) The algorithm is supported but the 
signature value is incorrect.

> discussion of the error cases, which aren't addressed in what follows.

Please let me know if there are any cases (other than those discussed 
above) that need clarification.

> Even if the all remaining signatures validate and cover the aggregate?

This is the issue of a particular IP address prefix being covered by 
both a valid and an invalid signature.

Personally, as indicated above, I think that either answer results in a 
reasonable path forward.

> trust anchors.  Depending on how the root of the RPKI ends up being

No, my intent certainly was *not* to require each EE certificate is 
validated using the same trust anchor.

My intent was to say that each EE certificate should be (independently) 
validated as per draft-ietf-sidr-res-certs.

> Exactly matches?  A covering match will not suffice?

We've had this discussion before with regards to a single signature on a 
ROA. If an entity has a CA certificate for the prefix 10.128/16 and 
wants to issue a ROA for 10.128.0/20, then the CA would issue an EE 
certificate for 10.128.0/20 and use this EE certificate to sign the ROA. 
Therefore, the current text of sidr-roa-format indicates that (in the 
case of a single signature) the IP address prefix in the ROA should 
indicate exactly the same set of IP addresses as the RFC 3779 extension 
in the corresponding EE certificate.

Similarly, with regards to multiple signatures, two CAs holding a 
covering range of IP addresses can each issue EE certificates so that 
the IP addresses in the union of addresses ranges of the EE certificates 
exactly match the IP addresses in the ROA.

Certainly, we could allow the addresses in an EE certificate to be a 
super-set of the addresses in the corresponding ROA, but I think its 
important that we use the same approach regardless of the number of 
signatures on the ROA.

---

From: Rob Austein <[email-masked]>
Date: Fri, 29 Feb 2008 18:42:46 -0500

I remain quite skeptical about the need for this, but will suspend
disbelief on that point for the remainder of this message.

The proposal is too complicated for the stated purpose, mostly because
it allows overlapping resource sets.  That drags in all sorts of fun
topics, such as partial overlaps, overlaps with multiple algorithms,
downgrade attacks, deciding how many good signatures is enough,
etcetera ad nauseum.

Complicated decision trees means multiple code paths.  Rarely used
code paths will be buggy.  Buggy code paths will be an attack vector.
This is supposed to be security software.  Keep it simple.

If you must support multiple signatures, do it as simply as possible:

- All signatures must be good, if any are bad, so is the ROA.  Full
  stop.

- Overlaps are not allowed, full stop.

- If the ROA's exactMatch field is true, the prefixes listed in the
  ROA must be an exact match for the union of the set of prefixes
  covered by the certs; otherwise, the prefixes listed in the ROA must
  be a subset (possibly improper) of the union of the resources in the
  cert.
_______________________________________________
Sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr