Skip to main content

Last Call Review of draft-ietf-sidr-rpsl-sig-10

Request Review of draft-ietf-sidr-rpsl-sig
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-05-09
Requested 2016-04-28
Authors Robert Kisteleki , Brian Haberman
Draft last updated 2016-05-12
Completed reviews Secdir Last Call review of -10 by Magnus Nystrom (diff)
Opsdir Last Call review of -10 by Al Morton (diff)
Assignment Reviewer Magnus Nystrom
State Completed
Review review-ietf-sidr-rpsl-sig-10-secdir-lc-nystrom-2016-05-12
Reviewed revision 10 (document currently at 12)
Result Has Issues
Completed 2016-05-12
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

- 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