[secdir] Secdir review of draft-ietf-sidr-rpsl-sig-10

[Magnus Nyström <[e-mail]>]

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This document describes a mechanism for digitally signing Routing Policy
Specification Language (RPSL) objects. The digital signatures are intended
to ensure authenticity and integrity protection of such objects when they
are transferred to and from resource databases.

- The signature scheme is a little unusual in that the signature attribute
lists the names of the attributes that are part of the signature rather
than just including those attributes (and their values) as part of the
signature attribute itself; I assume this is due to a need to preserve
established RPSL object syntax but it doesn't seem required for this
application which essentially is a transport format. The cost here is, of
course, the need to duplicate the names of the signed attributes in the
signed RPSL object (once for the regular attribute value and once for the
value in the signature attribute).
- There is an expectation that relying parties fetch the signer's
certificate based on a URL in the signature attribute. This may be a
dangerous practice, since the URL needs to be contacted before the
signature can be validated. A malicious party may insert a URL that will
lead to an attack. I suggest this be noted in the Security Considerations
section with some suggested best practice, e.g., only https and careful
parsing of the retrieved resource.
- The Signature Method field - how are new algorithms identified? Is there
no need for protocol action / IANA action to register new algorithm for use
with this memo?
-- As for the canonicalization, this is an inherently complicated field. It
does not, for example, seem as if the memo describes how to canonicalize
multi-valued attributes. The ordering of such values may well be
implementation-dependent post object parsing and thus, the canonicalization
should cover how to order sets or sequences of values.
- The last paragraph of the Security Considerations brings up an important
point but provides no guidance to an implementer how to handle this case /
detect the situation. Preferably some advice should be given here.

Editorial / questions:

Section 1:
- "This means when downloading a Routing Policy Specification Language
(RPSL) object stored in this database, one can reasonably safely claim that
the object is authentic, but for an imported object one cannot." Two
points: First part of sentence likely misses a "that." Secondly, what's
referred to with "this" database?
- "A maintainer of such signed database objects MUST possess a relevant
resource certificate, which shows him/her as the legitimate holder of an
Internet number resource." Why does a maintainer of objects need to possess
a resource certificate? I think the party generating signed database
objects need such a certificate, but not necessarily all maintainers?

Section 2:
- "When verifying the signature of an object, the verifier has to check
whether the signature itself is valid, and whether all the specified
attributes are referenced in the signature." What "specified" attributes?
- It would be very helpful with a full example, not just an outline as in
2.3.
- Section 2.4 talks about multiple signatures. I believe this is the only
place where this is done, and it is also confusing given that earlier text
stated that each attribute (and the signature is an attribute too), must be
present "at most once"?

Section 5:
- The certificate shouldn't be used for more than one verification - was
the intent to say that the private key associated with the public key
present in the certificate shouldn't be used to sign more than one RPSL
object? It seems difficult to state that a certificate can be used for
verification only once - multiple relying parties may verify it, for
example (note: I am not too familiar with RFC 6487 so may be missing
something here).

-- Magnus