Rob,
Thanks for your feedback.
I understand your skeptism about the need for multiple signatures.
Ultimately, no one can see the future well enough to know how often such
a mechanism will be needed. However, if the mechanism is needed and we
don't support it, it's not the kind of thing that can be added later in
any reasonable manner.
With regards to your comments, I'm happy to clearly specify that (1) All
signatures must be valid or the ROA; and (2) Two signatures covering
overlapping IP address ranges are not allowed.
With regards to the ExactMatch flag, the intent of the ExactMatch flag
is to specify the rules for matching the prefix(es) in a ROA with the
prefix(es) advertised in a BGP UPDATE. That is, when ExactMatch is TRUE
the AS must advertise exactly the prefix(es) listed in the ROA, where as
if ExactMatch is FALSE then the AS may advertise more specific (longer)
prefixes than those listed in the ROA. In either case, I belive the
addresses in the ROA should exactly match the (union) of the addresses
in the EE certificate(s) regardless of whether there is one or more
signature on the ROA.
Personally, I would like to see the specification dictate that any
SignerInfo whose digest algorithm is not SHA-256 be ignored (treated as
if it were not present) by the validation algorithm. I do not believe
this adds much additional complexity and I believe that if we do not
such a provision, then we will be stuck with SHA-256 forever (and if we
do add such a provision then at some point in the distant future the
spec could be updated to allow backwards-compatible migration to a new
digest algorithm).
That point aside for the moment, based on your comments I would propose
to re-write the ROA validation algorithm as follows.
[Please let me know if you have any suggestions for improving this text,
especially if you see a way to make the description simpler/clearer]
1. Verify that the ROA syntax complies with the syntax specified in
draft-ietf-sidr-roa-format. If the syntax is improper in any way, then
the ROA is invalid.
2. Process each SignerInfo object in the SignerInfos list, as follows:
2.1 Obtain an EE certificate whose Subject Key Identifier
(SKI) matches the sid field of the SignerInfo object.
This certificate may be obtained from the certificates field
of the SignedData object (if present), the resource PKI
repository system, or a local cache.
2.2 Use the public key in the EE certificate to verify the
signature on the ROA. If the signature is invalid then
the ROA is invalid.
2.3 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.)
If the EE certificate is invalid then the ROA is invalid.
2.4 Verify that the EE certificate has an IP Address Delegation
extension [RFC3779]. If the IP address range specificed in
the RFC 3779 extension overlaps with any IP address
range corresponding to a previous SignerInfo Object,
then the ROA is invalid.
3. Compute the union of IP address ranges in the RFC 3779
extensions of the EE certificates used to verify the signatures
in Step 2. If this union exactly matches the IP address
prefix(es) in the ROA, then the ROA is valid, otherwise it is
invalid.
Note: Again, I would propose adding a Step 2.0 that says "If the
digestAlgorithm of the SignerInfo object is not SHA-256, then ignore the
SignerInfo object and proceed to the next SignerInfo object."
- Matt Lepinski :->
Rob Austein wrote:
>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 protected]
>https://www.ietf.org/mailman/listinfo/sidr
>
>
>
_______________________________________________
Sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
